On 2011-02-03, at 17:45 , chevalma@iro.umontreal.ca wrote:
If string methods call one another, need the this argument, and are used-exposed, you could do it by simply calling them through "this."
Otherwise, if they aren't visible for the user, and don't really need to be accessible through String.prototype. I guess you could simply pass the string argument explicitly.
I only use 'this' when the method needs to be assigned to the String prototype of course. I'll keep the code as it is for now, but it'd be trivial to refactor it if we need to extract the bits of shared functionality.
As far as not using inline IR, I would try not to use it everywhere, but we technically can use it wherever we see fit in our own library code.
Not sure I'd like to implement String.prototype.split using IIR :)
Bruno
- Maxime
On 2011-02-03, at 17:20 , chevalma@iro.umontreal.ca wrote:
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue,
Doesn't that mean I will be forced to create a new array for the parameters though? Maybe we eventually such uses of apply could be optimized, but it sounds trickier to do than inlining the static call to me...
or iir.call if you know the number of arguments is fixed.
Most of these methods are not using inline IR, so that won't work.
Bruno
- Maxime
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