> The issue, is providing access to an already created symbol across such
> boundaries.  As I have pointed out in other messages, this isn't a problem
> that it unique to symbols.  It is isomorphic with use cases for sharing any
> kind of object across such boundaries.
>

I disagree.  The only reason this issue looks like a nail is because you're
gripping that symbol hammer so hard.  ; )  The problem is a quack.

This is duck-typing, plain and simple.  The only issue is what kind of a
quack we are looking for.  Do we identify the quack by using a flat
identifier namespace (as we typically do), or do we go for something
stronger?

There's nothing wrong with using "iterator" as the quack.  But the option
exists for something stronger, if we are willing to create the syntax to
support it.

Let's call it strong-duck-typing.  Instead of a quack being an identifier
in the flat namespace of identifier names, the quack is a globally unique
string.  There are only two sane options for globally unique names:  uuids
(or random equivalents) and DNS-based paths.  Let's arbitrarily choose
uuids.

We can do strong duck-typing now (and I actually use this in one of my
projects):

// UUID property names used for duck-typing
var ON_COMPLETE = "07b06b7e-3880-42b1-ad55-e68a77514eb9",
    IS_REJECTION = "7d24bf0f-d8b1-4783-b594-cec32313f6bc";


// Returns true if an object is a promise
function isPromise(obj) {

        return obj && obj[ON_COMPLETE];
}

// Returns true if a promise is a rejection
function isRejection(obj) {

        return obj && obj[IS_REJECTION] === true;
}


And with supporting syntax, we could make this really fluid:

// UUID property names used for duck-typing
var onComplete = "07b06b7e-3880-42b1-ad55-e68a77514eb9",
    isRejection = "7d24bf0f-d8b1-4783-b594-cec32313f6bc";


// Returns true if an object is a promise
function isPromise(obj) {

        return obj && obj.@onComplete;
}

// Returns true if a promise is a rejection
function isRejection(obj) {

        return obj && obj.@isRejection === true;
}


I hope this illustrates the general idea.  As I said, there's nothing wrong
with using "iterator" or "__iterator" but there is another option.

Kevin
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to