P T Withington ptw at
Wed Jun 28 13:22:18 PDT 2006

On 2006-06-28, at 15:00 EDT, es4-discuss-request at wrote:

> From: Nicolas Cannasse <ncannasse at>
> Date: 28 June 2006 12:33:10 EDT


Nicholas, lots of interesting ideas here.  I have a few comments.   
I'm just coming up to speed here, so pardon me if I am covering old  

> - A full reflection API. See for example the Reflect haXe class :  
> It has to use some tricks. In  
> particular the difference between an "object field" and a  
> "prototype field" is not very clear in JS, so for instance to get  
> the "object fields" you need to build a list with then  
> filter with hasObjectProperty.

Reflection conflicts with optimizations such as sealing (but then, so  
does having eval in your language).  That said, I would love to see a  
reflection API like Flash's ASSetPropFlags, which would allow user  
programs to create read-only, non-enumerable and un-deletable  
properties.  This would go a long way to being able to write a useful  
debugger in the language, instead of it having to be a separate  
program with a back-door.  It also makes it possible to write a leak- 
detector in the language.

The current proposal at 
enumerability.html is not really sufficient, since you have to  
already know the existence of a property to set its enumerability,  
but if you can't enumerate the property?  ASSetPropFlags allows you  
to set the flags on _all_ the properties of an object, so you can  
make them all enumerable (by enumerating them first, you know which  
ones to make un-enumerable when you are done).

Perhaps reflection and eval are turned off in strict mode?

> - 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;

> - 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 (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.

> - 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: 
H-26.html#%25_idx_4230.  (This would also be helpful writing a  

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

Please elaborate?


No comments on the last three items.


More information about the Es4-discuss mailing list