On Feb 18, 2014, at 11:29 AM, Mark S. Miller wrote:

> 
> 
> 
> On Tue, Feb 18, 2014 at 11:23 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> ...
> 
> It probably isn't appropriate for implementors to unilaterally decide whether or not this is a low priority feature.
> 
> Hi Allen, I agree with the rest, but I'm puzzled by your statement above. ES6 is large. It has many pieces. Implementors cannot do everything first. TC39 does not state a priority order among ES6 features so implementors must. It has always been thus.
> 
> 
>  
>  However, I can understand how they might reach that conclusion if application and framework authors aren't vocal if they consider it to be a high priority feature.
> 
> It is certainly valid and valuable for the community to provide feedback, to help implementors prioritize. But it is still the implementors that must make these priority order decisions.
> 

Sure, I'm just saying that these is a need to balance cost and utility when making implementation trade-offs  and that while implementors should always have a very good understanding of the cost it is up to the eventual users to make it clear if they consider a feature to have high utility.

I'm also a bit concerned, that there may be a meme starting that it will be a looooooong time  (years, if ever) before @@create is actually implemented so JS developers really shouldn't count on being able to use it if the foreseeable future.  Such a meme could become a self-fullying prophecy.

I agree that there is a lot of work to make all of the existing built-ins subclassable. But @@create is a basic part of the ES6 class design and comes into play even when built-ins aren't involved. 

My personal opinion is that classes should be a high priority features and that @@create based new behavior is a integral part of classes.  Hopefully we will start seeing implementations of that soon.  I'm actually considering fixing all the other subclassing issues of the existing built-ins to be a low priority.  But it would be nice is new built-ins such as Promises were implemented from the start to support subclassing.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140218/9e4310b8/attachment.html>

Sure, I'm just saying that these is a need to balance cost and utility when making implementation trade-offs  and that while implementors should always have a very good understanding of the cost it is up to the eventual users to make it clear if they consider a feature to have high utility.

I'm also a bit concerned, that there may be a meme starting that it will be a looooooong time  (years, if ever) before @@create is actually implemented so JS developers really shouldn't count on being able to use it if the foreseeable future.  Such a meme could become a self-fullying prophecy.

I agree that there is a lot of work to make all of the existing built-ins subclassable. But @@create is a basic part of the ES6 class design and comes into play even when built-ins aren't involved. 

My personal opinion is that classes should be a high priority features and that @@create based new behavior is a integral part of classes.  Hopefully we will start seeing implementations of that soon.  I'm actually considering fixing all the other subclassing issues of the existing built-ins to be a low priority.  But it would be nice is new built-ins such as Promises were implemented from the start to support subclassing.