domenic at domenicdenicola.com (2013-11-12T18:54:05.028Z)
On Fri, Nov 1, 2013 at 4:03 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > As Mark mentions in a subsequent message. ES6 O.p.toString only provides > brand checking for legacy ES<=5 built-ins. Hi Allen, perhaps I misunderstood. But I thought that as of ES6, O.p.toString can't be used for reliable brand checking of anything, including legacy ES<=5 built-ins. Not so? How would I do such a check of a legacy built-in in ES6?
On Fri, Nov 1, 2013 at 4:03 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > > On Nov 1, 2013, at 12:16 PM, Andrea Giammarchi wrote: > > > Allen I think we all agree duck typing is more flexible, powerful, easy, > etc etc ... but since you mentioned, how would do distinguish between a > `Map` and a `WeakMap` without passing through the branding check ? > > > > That's a very good example indeed, `'has' in obj` or `'set' in obj` does > not grant you any behavior with the signature itself (e.g. `WekMap` > does/did not accept primitives as key) > > You can behaviorally distinguish between a Map and a WeakMap by the > presence or absence of the 'forEach' or @@iterator property. But why would > you need to do that sort of discrimination? > > If you need a map that is Iterable and somebody passes you a WeakMap > that's a bug. An exception will be thrown when you try to iterate over it. > Similarly, if you need a map that accepts primitive values as keys and > somebody passes you a WeakMap that's also a bug and will result in > downstream exceptions. What are the use case where you would want to > accept either a Map or WeakMap and take different control paths depending > upon which as passed? > > > > > AFAIK WebIDL is entirely based on branding, regardless it's a good or a > bad thing, that's the way W3C describes "things" since quite ever (and > implement them in Java too ... anyway) > So? Why should that restriction be lifted in a manner that allows multiple > independent implementations or extensions of DOM interfaces to peacefully > coexist. > > > > > Why there's no easy way to check for branding if not abusing > `Object.prototype.toString` ? > > Because there is no single semantics for branding. What do you want you > brand to mean. For example, all of the branding in ES6 is subclass > friendly. Maps are branded and most Map methods will only work on Map > branded objects. But subclass instances of Map are (by default, you can > make it otherwise) are also branded such that the Map methods will work for > them. > > In other circumstances, a developer may decide that they do not want > subclass instances to share branding with a superclass. > > In some cases it may be desirable for an individual object to carry > multiple brands. > > You can look at Realm associations of ES functions as form of branding... > > What is the single easy test that encompasses all of these use cases, and > others > > > If so many libraries are using it because of the cross realm, maybe > there is a need for some similar mechanism and implemented in core would > make everybody life easier/faster ? > > Arguably, the real issue here is the ad hoc semantics of Realms that have > been implemented in browsers and the same-but-different built-ins that can > be referenced cross Realms. > > > > > The option you give us is: keep abusing `Object.prototype.toString` ... > that's OK but it seems to be a dirty solution. > > As Mark mentions in a subsequent message. ES6 O.p.toString only provides > brand checking for legacy ES<=5 built-ins. Hi Allen, perhaps I misunderstood. But I thought that as of ES6, O.p.toString can't be used for reliable brand checking of anything, including legacy ES<=5 built-ins. Not so? How would I do such a check of a legacy built-in in ES6? > It won't brand check Maps for you. That is intentional. > > Allen > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131101/b4d1310d/attachment-0001.html>