Harmony classes [Was: Operator overloading revisited]

[P T Withington]

On 2009-07-22, at 14:14EDT, Brendan Eich wrote:

> We all know many ways (too many!) to support inheritance. Would it  
> help to pick a winner prematurely, compared to giving people sugar  
> for high-integrity factories, which they must write the long way in  
> ES5, or not at all in current JS?


On 2009-07-22, at 10:39EDT, Alex Russell wrote:

> In short, it helps Harmony classes make all of the same mistakes  
> that DOM host objects currently plague developers with.

So, depending on your point of view, Harmony classes allow the user to  
create objects that have both the same integrity, and the same  
limitations, as native objects.

I suppose that's a start.  But if they don't even support prototypical  
inheritance, I'll never be able to use them.  Give them prototypical  
inheritance, and I will probably adopt them for their integrity, using  
my existing pre-processor to emulate the classes and mixins I really  
want.

My only quibble is whether it is confusing to name something so  
limited 'class'?

On 2009-07-22, at 10:52EDT, Mark S. Miller wrote:

> Lately Alex and I been
> reading <http://prog.vub.ac.be/Publications/2009/vub-prog- 
> tr-09-04.pdf>.
> Later today I will post some initial thoughts on how this could also
> be supported in within the same general framework.

Thanks for this pointer.  I am just starting to read and it looks  
intriguing.  Traits that also have state might just make me give up my  
mixins!