Tab is still looking for a MapLite (tm) that can be customized with
hooks. Obviously to avoid infinite regress, the MapLite bottoms out as
native, and the hooks are on the outside (in Map). Tab, do I have this
right?
The even simpler course is to keep Map as spec'ed and make DOM or other
specs work harder. Trade-offs...
/be
Allen Wirfs-Brock wrote:
On Jul 29, 2013, at 5:28 PM, Tab Atkins Jr. wrote:
On Mon, Jul 29, 2013 at 5:20 PM, Brendan Eich<[email protected]> wrote:
Brandon Benvie wrote:
. An Array would be identified the same way as it is currently in the ES6
spec: any object that is an Exotic Array Object would match 'Array'; for
map, any object that has [[MapData]] matches 'Map', etc (basically how
`Object.prototype.toString` figures out what to call something).
This still is privileged spec-only/builtin-only territory. How can user-code
make a Map-like that has [[MapData]]?
It can't, precisely because the spec is defined in terms of
[[MapData]]. If it were instead defined in terms of a SimpleMap with
just get/set/has/delete, user-code could handle it. Similarly with
other built-ins - they could be defined in terms of a simplified
version of themselves.
There seems to be some confusion here that is similar to thing that we are also
discussing in the "Proxy for Array transparency" thread...
There are various forms of "typing" that are used in the Es spec. and by ES programmers.
One of them is branding based upon the presence of various "internal data properties".
The ES Map specification implicitly defined a Map interface (let's call this
Mapish) as the behavior of its properties. Anybody can implemented an object,
in anyway they want, that supports the Mapish interface. Such an Mapish object
won't have (and doesn't need) a [[MapData]] internal property. Any Map client
(that only uses normal property [[Get]], [[Set]], [[Invoke]] operations) will
work fine on any Mapish object, regardless of the existence of a [[MapData]]
property.
On the other hand, every class that implements Mapish, will have to have
someway that its instances store the actual state required to fulfill the
Mapish interface. The bodies of the methods that are part of a specific
Mapish implementation will need to be coded using algorithms that understand
how its instances store that state. And, since ES methods can be easily
detached from an object and reattached to another. The methods of any
particular Mapish implementation need to verify that the actual this value they
are invoked upon use the stored state representation that the method
understands.
That is all that testing for [[MapData]] does in the ES6 spec. [[MapData]] is really
acting as a surrogate for "the actual Map state representation chosen by your
favorite ES engine". It makes sure that when Map.prototype.get tries to navigate
the hash table or binary tree, or whatever accessed at, let's say, offset +32 from the
pointer to the this value it won't get a seg fault (or worse) because the actual this
value is only 16 bytes long.
Nobody, other than implementers of Map really needs to think about [[MapDate]]
or similar private state of specified built-ins.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
