Killing `Promise.fulfill`

Mark Miller erights at gmail.com
Mon Aug 26 07:47:28 PDT 2013


The existing Array.from also copies the array-like, even if it is an array.
Clearly such a copying operation is useful. Whether this should be bundled
into Array.from, and whether .from is the right name if it is, are valid
questions.

However, my first reaction is, leave Array.from alone. It is not a coercer,
it is a copier. If we are agreed not to have the Promise constructor double
as the coercer (which is fine with me), then I think the coercer should be
called Promise.as. Besides subjective esthetics, I'm going to add a
seemingly silly "user interface" consideration: Promise.from is longer than
Promise.of. For the .then-level user, they seem identical -- they have no
observable difference. However Promise.from imposes a hidden storage costs
which we'd like the .then-level user to avoid paying, but brevity will lead
them to make the wrong choice. Promise() and Promise.as are no longer than
Promise.of, and so will not lead .then-level users astray.

If we do call the coercer Promise.from, as should rename the acceptor
Promise.accept rather than Promise.of. If we want an Array coercer rather
than an Array copier, we should consider renaming Array.from to Array.as.

Although seemingly silly, I actually make the above argument in all
seriousness. As Brendan says "notation is user interface." In user
interface design, path-of-least-resistance matters.





On Mon, Aug 26, 2013 at 1:42 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

> What do we think of having "from" be the coercer? By which I mean, change
> Array.from to return its input if given a true Array (or
> properly-subclassed one with [[ArrayInitialisationState]] set to true,
> maybe??). Then Promise.from could follow that semantic, returning the input
> if it's a true promise or coercing it otherwise.
>
> I can't see how this would hurt Array.from's use-case, which is usually
> going to be something like `Array.from(arrayLike).forEach(…)`. And it fits
> the use case promises want perfectly.
>
> On Aug 26, 2013, at 3:49, "Brendan Eich" <brendan at mozilla.com> wrote:
>
> > Kevin Smith wrote:
> >> I don't think you'll want to have divergent behavior for construct vs.
> call with new APIs.  I believe that would go against Allen's approach for
> new ES6 built in classes, and beyond that, it unnecessarily overloads the
> API surface.  Different operations ought to have different names.
> >
> > +1.
> >
> > Date is just a botch.
> >
> > Boolean, Number, and String are legacy special cases, not to be imitated
> by Promise (not a value type coercer when called, primitive wrapper object
> constructor when new'ed).
> >
> > /be
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130826/41936498/attachment-0001.html>


More information about the es-discuss mailing list