typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
brendan at mozilla.com
Thu Aug 1 17:29:44 PDT 2013
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
The even simpler course is to keep Map as spec'ed and make DOM or other
specs work harder. Trade-offs...
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<brendan at mozilla.com> 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.
More information about the es-discuss