On 2010-06-07, at 9:30 PM, chevalma@iro.umontreal.ca wrote:
- You can only use functions from that namespace once the whole namespace
object is constructed. This will make the construction of constant tables awkward (when the elements of the table are objects whose constructor is defined in the namespace). This happens for example in scanner.js, and I expect it to occur in many other places in the compiler.
That's a good point. However, we could also use a different syntax where we define the module first as the empty object, and add functions later. This would address that issue, you then simply have to make sure that functions were defined before calling them. And as I've just said, these could be made read-only.
Did you try to do this (i.e. make properties read-only)? You hinted at a way (which does not work as is) and the spec is not clear and I can't get it to work (because [[Writable]] is an internal property).
You did not answer this important question: how will a *client* module know that mem is a namespace with read-only fields (thus enabling the compiler to perform direct jumps)?
KISS... so I propose we use identifier prefixing at first. If it becomes a problem we can refactor the code (changing client code is trivial... a sed script to map "memory_" to "memory.").
It's mostly a problem with JsDoc. It doesn't separate functions by file, or sort them by name, as far as I've noticed... Because JavaScript programmers don't tend to just write all functions in the top level.
If it sorts by name then all the mem_xxx functions will be together. What's the problem?
So I propose this notation instead:
/** @namespace */ memory = {}
/** Adds a signed offset to a pointer value @param ptr pointer to raw memory @param val signed offset */ memory.ptrAdd = function(ptr, offset) { }
/** Computes the difference between two pointers */ memory.ptrSub = function(ptr1, ptr2) { }
Because:
- JsDoc can document this effectively
Same for mem_xxx.
- It's easy to understand
Same for mem_xxx.
- Solves the ordering issue you mentioned
It is not an issue with mem_xxx. But with mem.xxx you will be calling methods in the mem object before the fields are made read-only. How will tachyon deal with such a case (a namespace being used in the middle of its initialization)? This will cause problems with the static analysis. In other words, how will the compiler know which fields of the namespace object have been defined when the code reaches the call mem.xxx ? Also, where will the field "xxx" be in the mem object, after all we are incrementally adding fields to a hash-table, so the hash-table may have to be resized, which will move the fields around during the initialization. Not a good thing!
- It's also a clearer, more sensible style
"more sensible"!!!! come on!!!!!
- It's more in line with the way people actually use JavaScript
That's true, but lets put things into perspective... We are talking about a single character in the "function name", either a "_" or a ".". This is not exactly a big change in style! On the other hand we can expect a factor of 2 speed difference between "_" and ".". That's significant.
The mem_xxx style is clearly more KISS than the mem.xxx style.
Marc