Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

>> I'd be a much happier camper if I didn't have to think about handling
different return values.

I agree, and If it were up to me, there would be just one API for
document.register.

However, the argument given for dividing the API is that it is improper to
have a function return a value that is only important on some platforms. If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?


On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> I agree with your approach on staging the two specs for this, but the last
> part about returning a constructor in one circumstance and undefined in the
> other is something developers would rather not deal with (in my
> observation). If I'm a downstream consumer or library author who's going to
> wrap this function (or any function for that matter), I'd be a much happier
> camper if I didn't have to think about handling different return values. Is
> there a clear harm in returning a constructor reliably that would make us
> want to diverge from an expected and reliable return value? It seems to me
> that the unexpected return value will be far more annoying than a little
> less mental separation between the two invocation setups.
>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Corporation
>
>
> On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>
>> On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner <daniel@mozilla.com>
>> wrote:
>> > I'm not sure I buy the idea that "two ways of doing the same thing does
>> not
>> > seem like a good approach" - the web platform's imperative and
>> declarative
>> > duality is, by nature, two-way. Having two methods or an option that
>> takes
>> > multiple input types is not an empirical negative, you may argue it is
>> an
>> > ugly pattern, but that is largely subjective.
>>
>> For what it's worth, I totally agree with Anne that two-prong API is a
>> huge wart and I feel shame for proposing it. But I would rather feel
>> shame than waiting for Godot.
>>
>> >
>> > Is this an accurate summary of what we're looking at for possible
>> solutions?
>> > If so, can we at least get a decision on whether or not _this_ route is
>> > acceptable?
>> >
>> > FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>> >   prototype: ELEMENT_PROTOTYPE,
>> >   lifecycle: {
>> >      created: CALLBACK
>> >   }
>> > });
>>
>> I will spec this first.
>>
>> >
>> > FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>> >   constructor: FOO_CONSTRUCTOR
>> > });
>> >
>>
>> When we have implementers who can handle it, I'll spec that.
>>
>> Eventually, we'll work to deprecate the first approach.
>>
>> One thing that Scott suggested recently is that the second API variant
>> always returns undefined, to better separate the two APIs and their
>> usage patterns.
>>
>> :DG<
>>
>
>