Nicolas Cannasse ncannasse at
Wed Jun 28 23:06:26 PDT 2006

 >> - how you will support interitance ? Will you be able to create your
 >> own prototype-chains ? In haxe you can "implements" classes. Be able
 >> to add add object in the subtyping relation would help.
 > Not sure I follow you here.  You can already create arbitrary prototype
 > chains in ECMAScript:
 >   function makeInheritedHash (parent) {
 >     if (parent) {
 >       function xtor() {};
 >       xtor.prototype = parent;
 >       return new xtor();
 >     }
 >     return new Object;
 >   };

Yes but it's a single list.
When you start having interfaces in the language, it means that you have 
several supertypes. It would be interesting to access/modify this 
supertype list used for runtime subtyping.

 >> - the ability to create "naked" objects, with no prototype, and no
 >> magic field, so every field of the object can be freely manipulated.
 >> It would be nice to be able to idenpendantly set the object prototype
 >> and set the "field" prototype. For instance Neko gives prototype
 >> access through primitives $objgetproto and $objsetproto instead of
 >> giving "magic" access through .prototype or __proto__.
 > This can be simulated in current ECMAScript by filtering with
 > hasOwnProperty, but I agree that it is a wart that is too easy to
 > stumble over (using an Object as a HashTable and not realizing that
 > there are some keys 'already defined'). I think this could be solved by
 > letting you set a constructor's prototype to null, but the spec would
 > have to specifically state that this must be supported

Yes for example this works on current Safari JS implementation I think.

 > (it would have to
 > define what operations must work on objects with no prototype).  Making
 > an object with a null prototype breaks several current implementations.

Accessing fields for reading/writing looks enough.

 >> - exceptions with complete stack traces : not as strings but as
 >> objects, so we can easily extract the line numbers and replace them by
 >> the original language file/line numbers. That can also be implemented
 >> by the ability to add specific comments in generated code, such as :
 > Isn't this really just part of your introspection request?  IWBN to have
 > introspection interfaces to the execution context.  As long as we are
 > re-implementing Lisp, eval needs to take an execution context as an
 > argument:
 > (This would also be helpful writing a debugger).

Actually, there is another way to do this. If the exception stack trace 
gives the file+line table representation the stack, then we can do 
appropriate replacements by remaping line X of the generated JS to the 
file/line of the original files.

 >> - "magic" fields __resolve, __call and __get/__set (array accesses)
 >> would help to implement several kind of highlevel features 
 > Please elaborate?

For instance, when an unknown field is accessed in ActionScript2, 
__resolve is called instead (if exists). It has an argument which is the 
field name.

When an object is used as a function and called, the __call method could 
be invoked with the list of arguments.

Here's an exemple of what is happening at runtime :

o.unknownField    => o.__resolve("unknownField") = 0         => o.__setfield("xxx",0)
o(1,2,3)	  => o.__call(1,2,3)
o[56]		  => o.__get(56) // or __resolve(56) ?
o[56] = 5	  => o.__set(56,5) // or __setfield(56,5) ?

This can be optimized correctly by storing some bits in the object 
telling which magic accessor it has. This then only require one 
additional test in some specific cases.


More information about the Es4-discuss mailing list