domenic at domenicdenicola.com (2013-11-12T18:53:09.394Z)
On Nov 1, 2013, at 10:40 AM, Anne van Kesteren wrote: > So this is basically what we have for DOM objects right now. And what > we're asking for is having this elevated to language-supported > construct. Be it in the form of a method or something else. It's not > really clear why sometimes you would use if "brand in obj" and other > times "Array.isArray(obj)". Seems rather messy. Array.isArray is a legacy artifact so I'm not going to try to generalize from it. But, in general, the distinction is between asking "does this object appear to expose the behavior I need" and "is this object an instance of a specific known implementation of the behavior I need". Let's call the first question "duck typing" and the second "branding". Duck typing is a weaker test but allows for a lot of flexibility and extensibility. Branding gives you reliable knowledge about certain aspects of a branded object. But it is less flexible and and systems that extensively using branding are often harder to extend. IMO branding is over used. Array.isArray is a specific brand test based upon how the implementation of how property definition interacts with the value of the 'length' property. ES currently proves lots of ways to do duck type testing. Built-in objects (including host objects) can implement branding and brand testing using various techniques but ES currently (including ES6) is very limited in its language level sort for reliable branding. The best we have to offer in ES6 is WeakMaps. In the future, we probably will add mechanism that make it easier to define branded objects defined via ES code. But, before you brand something really think carefully about why you need such a brand. It may not really be necessary.
On Nov 1, 2013, at 10:40 AM, Anne van Kesteren wrote: > On Fri, Nov 1, 2013 at 12:50 AM, Allen Wirfs-Brock > <allen at wirfs-brock.com> wrote: >> [isSpecialString]() {return isSpecialString in this}; > > So this is basically what we have for DOM objects right now. And what > we're asking for is having this elevated to language-supported > construct. Be it in the form of a method or something else. It's not > really clear why sometimes you would use if "brand in obj" and other > times "Array.isArray(obj)". Seems rather messy. Array.isArray is a legacy artifact so I'm not going to try to generalize from it. But, in general, the distinction is between asking "does this object appear to expose the behavior I need" and "is this object an instance of a specific known implementation of the behavior I need". Let's call the first question "duck typing" and the second "branding". Duck typing is a weaker test but allows for a lot of flexibility and extensibility. Branding gives you reliable knowledge about certain aspects of a branded object. But it is less flexible and and systems that extensively using branding are often harder to extend. IMO branding is over used. Array.isArray is a specific brand test based upon how the implementation of how property definition interacts with the value of the 'length' property. ES currently proves lots of ways to do duck type testing. Built-in objects (including host objects) can implement branding and brand testing using various techniques but ES currently (including ES6) is very limited in its language level sort for reliable branding. The best we have to offer in ES6 is WeakMaps. In the future, we probably will add mechanism that make it easier to define branded objects defined via ES code. But, before you brand something really think carefully about why you need such a brand. It may not really be necessary. Allen