On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

>
> On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
>
> > A variety of places in the spec use the new IsConstructor abstract
> operation. In ES5, this test (essentially, "does the object implement the
> [[Construct]] internal method") was restricted to the `new` operator. But
> in ES6, it is used in implementing a large variety of built-in functions:
> >
> > - All Array methods
> > - All %TypedArray% methods
> > - All Promise methods (via NewPromiseCapability)
> >
> > (Note that there are two uses: arrays and typed arrays do alternative
> logic for non-constructors; promises fail immediately. This inconsistency
> might be a bug?)
>
> Maybe you're looking at things differently from me, but I only see use of
> IsConstructor in a few Array methods, not all of them.
>
> For most places in the spec. if you trace the logic of the algorithms that
> use IsConstructor it be being used as a guard on a [[Construct]] call and
> the alternative path is to throw a TypeError.  In ES code this would be
> done automatically by the 'new' operator but must be done explicitly in the
> pseudo-code. A  JS self-hosted implementation of those algorithm that used
> 'new' would not need to do an explicit IsConstructor test in most of those
> cases.
>
> There are a few uses of IsConstructor in some Array methods that deal with
> subtle backwards compat issues that are a result of extending Array to be
> subclassable.  These are very unique cases and I don't think you should
> look at them as establishing a pattern that should be followed in other
> situations.
>
> Array.from and Array.of have a non-throwing IsConstrutor test because they
> are designed to allow things like this:
>
> let of = Array.of;
> of(1,2,3,4,5);   //Equivalent to: Array.of(1,2,3,4,5)
>
> I don't recall why we provided that functionality.  It doesn't seem to me
> like a pattern we should want to encourage.
>
> >
> > It seems to me that we should expose this primitive reflective operation
> to users, instead of having all of these methods be able to detect
> something that user code can't, and thus making them harder to explain or
> polyfill.
>
> Most of these uses are simply emulating the behavior of the 'new' operator
> so it really shouldn't be needed to be tested explicitly in a polyfill.
>  When it is really need, a user land IsConstructor test can be written
> using Proxy.
> >
> >
> > Alternately, if we don't think users should be doing this kind of
> reflection, then we probably shouldn't be doing it ourselves. In which
> case, figuring out an alternate path for the above methods would be
> useful---perhaps they simply try to construct, and fail immediately if used
> with a non-constructible object, instead of falling back.
> >
> > WDYT?
>
> Other than the Array.of and Array.from usages the other uses are all
> necessary either functionally (you can't just "try to construct" by calling
> [[Construct]], it requires an explicit guard) or to deal with special
> backwards compat situations.
>
> I'd be happy to eliminate the special handling in Array.of and Array.from
> if there is consensus that it isn't desirable.
>
>

I don't see the incentive in removing the special handling from these two
cases when there is obvious end-programmer benefit: minifiers can safely
alias Array.of and Array.from without needing to use .bind(Array) when
declaring that alias.


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/7de0e89c/attachment.html>

On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> I'd be happy to eliminate the special handling in Array.of and Array.from
> if there is consensus that it isn't desirable.

I don't see the incentive in removing the special handling from these two
cases when there is obvious end-programmer benefit: minifiers can safely
alias Array.of and Array.from without needing to use .bind(Array) when
declaring that alias.