On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
I think we might also perhaps want to add some kind of global variable that only exists when compilation occurs under Tachyon. This would allow the array and string implementations to use conditional tests (eg: if (TACHYON_JSVM !== undefined)) to change their implementation depending on whether they're running on V8 or Tachyon.
That sounds like a C "#ifdef", but at run time. It's kind of dirty, but I guess we can use it until we find something cleaner.
Marc