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

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