On Oct 16, 2011, at 10:19 PM, David Herman wrote:
>> I agree with Andreas. The implicitly-called base level methods are not
>> meta-methods or (spec language) "internal methods". They do not need their
>> own traps. They are base-level property accesses.
>
> Well, certainly that's the way the language currently works. But the way it
> currently works is problematic, because you can't define an object that is
> convertible to string without using the toString name.
Yes, you're right. I didn't mean to make that necessity a virtue.
>> And if someone does enter 'toString' or 'valueOf' into a Dict, let the chips
>> fall where they may.
>
> Well of course someone should be allowed to enter 'toString' into a Dict. But
> why shouldn't it be possible to define robust string conversion for an object
> without having to pollute the object's namespace?
After you and David sorted me out, I think the main thing is to avoid more
magic unstratified traps in all objects. A proxy can afford a derived
defaultValue trap. One might argue that for implicit conversion, base-level
objects could afford a private-named defaultValue trap too. I suspect
implementors will complain and this will hit the stupids (SunSpider in
particular). But I could be wrong.
>> That was proposed separately:
>>
>> wiki.ecmascript.org/doku.php?id=strawman:dicts
>
> Yup, I remember writing it. ;-) But ES5 pretty much already gives you the
> ability to define such an object, with the exception of the result of typeof
> and the fact that [[ToString]] and [[ToPrimitive]] break. What I'm proposing
> is that we clean up these places in the semantics that currently look for
> concrete names in favor of something stratified.
If dicts must be proxies the economics are wrong, as you noted on twitter.
If dicts are objects, they don't behave like other objects. We could then (a)
extend object (as you sketch below) with optional unstratified, private-named
traps. Or we could (b) make dicts a new typeof-type as your strawman (I was
teasing, I remembered you wrote it ;-) proposes.
I think we're on the slippery slope doing the latter. Unstratified traps for
iterate and defaultValue (let's say -- not toString and valueOf separately),
won't cut it. All the other proxy traps will be wanted, e.g. as in the
wiki.ecmascript.org/doku.php?id=strawman:observe strawman.
Python goes all-in with __ugly__ trap names. We've studied these for
wiki.ecmascript.org/doku.php?id=strawman:value_proxies but the proxy
(non-native) nature of those saves us, we think. The problem is base-level
private-named traps triggering novel control flow in real engines. Currently
these will mean a performance hit. With enough implementation work, perhaps
they won't -- but then there's the implementation work to count.
I'm not convinced we want to take door (a), not just for dicts. At the May TC39
meeting, for observe-like watchpoints, we talked about marrying proxies and
base-level objects without deoptimization using becomes. I think Arv has news
on this front, so I'll let him speak.
/be
>
> One possibility might be to create some private names, à la |iterate|, which
> you could use in place to 'toString' and 'valueOf':
>
> js> import { toString, valueOf } from "@meta";
> js> var obj = Object.create(null, {});
> js> String(obj)
> TypeError: cannot convert obj to string
> js> obj[toString] = function() { return "hello world" };
> js> String(obj)
> "hello world"
>
> This isn't exactly stratified like proxies, but it at least leaves room to
> unreserve the meaning of 'toString' and 'valueOf'.
>
> Dave
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
