On 2011-02-03, at 16:01 , Marc Feeley wrote:
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.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno