Suggestions
P T Withington
ptw at pobox.com
Wed Jun 28 13:22:18 PDT 2006
On 2006-06-28, at 15:00 EDT, es4-discuss-request at mozilla.org wrote:
> From: Nicolas Cannasse <ncannasse at motion-twin.com>
> 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
ground.
> - A full reflection API. See for example the Reflect haXe class :
> http://haxe.org/api/Reflect. 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 for...in 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 http://developer.mozilla.org/es4/proposals/
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: http://mitpress.mit.edu/sicp/full-text/book/book-Z-
H-26.html#%25_idx_4230. (This would also be helpful writing a
debugger).
> - "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.
--ptw
More information about the Es4-discuss
mailing list