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.

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"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/a5a3a74c/attachment.html>

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.

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