On Sat, Dec 28, 2013 at 8:35 AM, Sebastian Markbåge
<sebastian at calyptus.eu<javascript:_e({}, 'cvml',
'sebastian at calyptus.eu');>
> wrote:

> I completely agree that is the intended use and what we should be
> encouraging people to do. What I'm asking for is to intentionally break
> best-practices for a specialized use case.
>
> The use case I had in mind was React components. Components in React are
> described as classes which makes them seem approachable to a broad user
> base. They cannot and should not be accessed as class instances though. The
> instances are immutable data structures used exclusively by the library.
> The base constructor could look something like this:
>
> constructor(x) {
> return { _hiddenInstance: this, _instantiationContext: CurrentContext,
> _id: uid(), _someArgument: x };
> }
>


> This would generate a descriptor that can be used by the library but only
> used as a reference by the user. This allows users to declare classes just
> like they're used to and even instantiate them normally. However, they'd
> only be given access to the real instance at the discretion of the library.
>

We're doing this with Maps (for non-DOM bound data) and WeakMaps (for DOM
bound data) in the FirefoxOS Messages app (for Recipients, Threads and
Draft data objects).

Rick


>
> Of course, we could have all users wrap their classes in some kind of
> decorator constructor and that's probably where we'll end up for clarity.
> It's would've been a neat pattern though.
>
>
>> Regarding adding 'return' to the default constructor body.  It appears
>> that technically it would be a benign change.  However, the only reason to
>> do so would be accommodate superclasses that deviate from the above
>> patterns.  In that case, you are probably already in the weeds.  I'm not
>> sure that we should be trying to facilitate such deviations.
>
>
> It seems to me that whether we add it or not is arbitrary. By not adding
> it we're intentionally removing this use case (forever). IMO we need to
> have a reason to intentionally prevent a use case if it could be easily
> supported. I'd buy almost any argument here except that it's in bad taste
> to use this pattern.
>
> If we have reason to believe that this pattern will be harmful, do we also
> have to do more to prevent normal constructors from returning anything
> other than "this"?
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <javascript:_e({}, 'cvml',
> 'es-discuss at mozilla.org');>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/fec23990/attachment.html>

On Sat, Dec 28, 2013 at 8:35 AM, Sebastian Markbåge <sebastian at calyptus.eu> wrote:

> I completely agree that is the intended use and what we should be
> encouraging people to do. What I'm asking for is to intentionally break
> best-practices for a specialized use case.
>
> The use case I had in mind was React components. Components in React are
> described as classes which makes them seem approachable to a broad user
> base. They cannot and should not be accessed as class instances though. The
> instances are immutable data structures used exclusively by the library.
> The base constructor could look something like this:
>
> ```js
> constructor(x) {
> return { _hiddenInstance: this, _instantiationContext: CurrentContext,
> _id: uid(), _someArgument: x };
> }
> ```
>
> This would generate a descriptor that can be used by the library but only
> used as a reference by the user. This allows users to declare classes just
> like they're used to and even instantiate them normally. However, they'd
> only be given access to the real instance at the discretion of the library.

We're doing this with Maps (for non-DOM bound data) and WeakMaps (for DOM
bound data) in the FirefoxOS Messages app (for Recipients, Threads and
Draft data objects).