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

What is the harm in returning the same constructor that is being input for
this form of invocation? The output constructor is simply a pass-through of
the input constructor, right?

FOO_CONSTRUCTOR = document.register(‘x-foo’, {
  constructor: FOO_CONSTRUCTOR
});

I guess this isn't a big deal though, I'll certainly defer to you all on
the best course :)

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles <sjmiles@google.com> wrote:

> >> 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<
>>>
>>
>>
>