On May 23, 2011, at 8:31 AM, Brendan Eich wrote:
> On May 23, 2011, at 6:11 AM, Irakli Gozalishvili wrote:
>> On Monday, 2011-05-23 at 13:10 , Dmitry A. Soshnikov wrote:
>>
>>> On 23.05.2011 14:17, Irakli Gozalishvili wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think there lot's of proposals for ES.next that require syntax
>>>> extensions, which is probably worth if new functionality added or shortens
>>>> most commonly used constructs like functions (were no other option is
>>>> available). In case of this proposal:
>>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
>>>> even though
>>>> I like it I'm not sure adding new syntax is worth it.
>>>>
>>>
>>> May I ask a counter question -- why do you think it's not good to add
>>> syntactic sugar for classes? It's a kind of a strange thing. People
>>> sometimes talk about unnecessarily of a sugar. But why I'm asking? Is it
>>> bad to use a sugar? Or do you _really_ worry about an _implementation_ that
>>> e.g. a language will be "too heavy"? After all, it's not even the issue of
>>> users, it's the issue of implementers.
>>>
>> Dimitry thanks that's very good question.
>>
>> 1. More syntax means larger language surface, which adds complexity more
>> things to remember / learn. More things to consider in ES.next.next
>
> It's true, although not everyone learns it all up front. Especially where new
> syntax is not yet supported in all browsers, and the student is not using a
> compiler to translate new to old version.
>
> I think the sharper version of your (1) is: "class syntax is too much syntax
> to solve the problems people have with prototypal inheritance: subclassed
> prototype/constructor set-up and super calls."
>
> I agree with that. Allen had been proposing super support that was separate.
> You proposed Function.prototype.extend. Perhaps there's enough there to
> relieve us of the large, tradition-haunted ediface of classes.
>
>
>> 2. I OOP in JS is already confusing for people coming from other languages,
>> this proposal will make it even more confusing.
>
> This is not as on target, in my opinion, because even if overwrought, classes
> are trying to solve some confusion or accident hazards in JS today to-do with
> prototypal inheritance. Namely,
>
> (A) the boilerplate needed to set up a sub-prototype object with correct
> constructor property, and
>
> (B) the pain of doing correct super calls by hand.
I hope we can add the hazards of incorrectly adding mutable state to a
prototype and not an instance to this list. I.e., many people get this wrong:
function C(){
// should include:
// this._list = [];
}
C.prototype = {
_list: [],
addToList: function(item) {
this._list.push(item); // logic error!
// side-effects here
}
};
Allen and I have discussed this before, so it's not a surprise, but I'm worried
that some proposals might omit fixing this on their todo list.
> Can we agree that these are problems to be solved, if not by classes then by
> other APIs or special forms?
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
[email protected]
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
