On Nov 1, 2013, at 10:40 AM, Anne van Kesteren wrote:
> On Fri, Nov 1, 2013 at 12:50 AM, Allen Wirfs-Brock
> <al...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
