Hi,
Since your response does not really answer my point (definition of
fundamental traps), I take the responsibility to change the title and
provide an answer.
I am not an ECMAScript expert and not involved in the TC-39 commitee,
but here are my answers.
Overall, I think (I may be wrong) that you're confusing two different
concepts which are :
- ECMAScript objects which are "regular objects", a set of properties
with all the semantics that we are all used to and which any programmer
can create through "new Object()" (or "{}" for lazy people like myself);
- The Object Type (ECMAScript 5 section 8.6) in the broad sense which
includes "regular objects", "host objects" and maybe soon proxies.
The former are an "instanciation" of the latter with the semantics that
is defined in ES5 section 8.12 (Algorithms for Object Internal Methods).
Proxy will be one with programmer-defined semantics.
As far as I understand proxies, they are not designed to provide
garantees toward acting the same way as regular objects do (even for the
prototype chain behavior). They aim at allowing the programmer to FULLY
redefine in ECMAScript the semantics of operations on object besides
some core operations (typeof, ===, Object.getPrototypeOf, instanceof, am
I forgetting one?) which are some core garantees that define the object
type (ES5 section 8.6) identity.
Actually, as I am writing it, I am realizing that only "typeof" and
"===" are really part of the object type identity.
But it can be read
(http://wiki.ecmascript.org/doku.php?id=harmony:proxies#interaction_with_instanceof)
that 'Object.getPrototypeOf' ([[Prototype]]) isn't trapped because it
would provoke an inconsistant behavior for instanceOf
and 'instanceof' have been decided to not be trapped because of a
security issue.
I think that the main idea behind proxies isn't consistency. It's power.
In "Harmony of my dreams"
(http://brendaneich.com/2011/01/harmony-of-my-dreams/), Brendan Eich's
quotes Guy Steele on language growth:
"We need to put tools for language growth in the hands of the users.".
First i agree with this and second of all, proxies are going in that
direction.
I share your concern that it's a powerful and then dangerous feature for
consistency's sake, but "with great power, comes great responsibility".
It's up to the people who are going to use proxies to be careful to be
coherent with what they pretend to do. And there are already some
mecanisms that helps consistency like derived traps or even the Default
Proxy forwarding handler proposal
(http://wiki.ecmascript.org/doku.php?id=strawman:proxy_defaulthandler&s=forwarding)
David
Le 23/01/2011 17:43, François REMY a écrit :
> Moreover, should a Proxy really have a prototype ?
> I mean, what’s the point about having a prototype, since the “get”
> method can return everything you would like for any property ?
>
> I think getProtototypeOf should be defined as a new trap. And its
> default behaviour should be to return null (or Object.prototype, but I
> think null is the intented behavior of a proxy).
>
> On the other hand, overriding getPropertyNames should not be allowed.
> getPropertyNames should *always* return the concatenation of the
> properties returned by getOwnPropertyNames() and by
> getPrototypeOf(this).getPropertyNames(). It makes no sense otherwhise.
>
> I understand that we may want to redefine the way an ECMAScript Object
> can handle the native commands, but I’m strongly against anything that
> can conduce to illogical results (if there’s not an use case that
> justify it, naturally). The definition of getPropertyNames is clear
> and being able to redefine it locally seems me wrong. A proxy can
> modify is own behavior, not the behavior of the ES engine. Being able
> to have getPropertyNames and getOwnPropertyNames returning
> incompatible results is somewhat hurting me. Is there any reason we
> should allow that ? Any use case ?
>
> I’m issuing the same concerns for the “has” trap. It think it should
> not be a trap. It should always return hasOwn(key) ||
> prototype.has(key). Each one of hasOwn and prototype can be tuned by
> the proxy, but not the “has” itself. We’re not removing features, but
> we prevent bad usage of it. Whatever the user code do, the ‘has’
> behavior will stay logical.
>
> Another thing I don’t quite understand is the difference between
> “keys” and “enumerate”. If there’s no strong difference, it should be
> the same trap (same logic: enumerate should return the concatenation
> of this.keys and this.prototype.keys). Having two different but
> similar traps will cause confusion. Maybe there’s a need for this
> difference however. I just didn’t understand why such a difference
> should exist, but at least I see more possible usages than the first
> three traps I “contested”.
>
> Anyway, if we should retain only one thing from the discussions we
> already have seen on the Proxy hub, is that it’s a great feature, but
> one that still needs some work before implementation ;-)
>
> Regards,
> François
>
> *From:* David Bruant <mailto:[email protected]>
> *Sent:* Sunday, January 23, 2011 4:24 PM
> *To:* es-discuss <mailto:[email protected]>
> *Cc:* Mark S. Miller <mailto:[email protected]>
> *Subject:* [ES Harmony Proxies] Fundamental trap definition
>
> Hi,
>
> I am wondering if getPropertyDescriptor and getPropertyNames
> fundamental traps shouldn't rather be derived traps since they could
> have a pretty straightforward default implementation.
> One implementation of getPropertyNames could be :
> --------------------------
> Object.getPropertyNames = function(o){
> var objectToInspect;
> var result = [];
>
> for(objectToInspect = o;
> objectToInspect !== null;
> objectToInspect = Object.getPrototypeOf(objectToInspect))
> {
> result =
> result.concat(Object.getOwnPropertyNames(objectToInspect));
> }
>
> return result.removeDuplicates(); // the removeDuplicates method
> is made up, but you get the point
> }
> --------------------------
> This seem to fit the proposal
> (http://wiki.ecmascript.org/doku.php?id=harmony:extended_object_api&s=getpropertydescriptor)
> expectations). This could be also the default getPropertyNames trap
> implementation.
>
> I haven't really seen a strong definition of what fundamental traps
> are in the proposal. On Mark Miller's e-mail
> (https://mail.mozilla.org/pipermail/es-discuss/2011-January/012601.html)
> is written:
> [a trap is fundamental if] there is no coherent default behavior to
> fall back to that would be defined in terms of the remaining traps.
> (please tell me if I misinterpret what you meant)
> If we're going with this definition, then getPropertyDescriptor and
> getPropertyNames should probably be derived traps since they can
> clearly be defined thanks to other traps (respectively
> getOwnPropertyDescriptorand getOwnPropertyNamesas I showed above)
> which seems to be coherent fallback behavior.
> Instead of a formal definition, this could be a rational for deciding
> what is a fundamental trap and what isn't.
>
> In the 5 remaining traps (getOwnPropertyDescriptor,
> getOwnPropertyNames, defineProperty, delete, fix), I don't see any
> that could be defined thanks to the others. They seem to be also the
> fundamental actions that one can perform on a single object:
> Property-wise:
> - create/configure a property (defineProperty)
> - delete a property (delete)
> - retrieve a property (getOwnPropertyDescriptor. Can be used to
> separate the create and configure cases of defineProperty)
> Property-set-wise:
> - retrieve the property set (getOwnPropertyNames. More can be found
> later on each property with getOwnPropertyDescriptor)
> - prevent further extension (and optional reconfigurations for seal
> and freeze)(fix)
> The prototype can be retrieved thanks to Object.getPrototypeOf (which
> cannot be trapped for consistency purposes) and all actions can be
> performed by climbing the prototype chain.
>
> Any thoughts on the fundamental trap definition?
> Or on the idea of turning getPropertyDescriptor and getPropertyNames
> into derived traps with the suggested definition?
>
> David
>
> ------------------------------------------------------------------------
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
