On Sat, Oct 29, 2011 at 10:31 PM, Rick Waldron <[email protected]> wrote:
>
>
> On Oct 30, 2011, at 1:03 AM, John J Barton <[email protected]>
> wrote:
>
>> On Sat, Oct 29, 2011 at 4:34 PM, Axel Rauschmayer <[email protected]> wrote:
>>> http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern
>>>
>>> const className = superClass <| function(/*constructor parameters */) {
>>> //constructor body
>>> super.constructor(/*arguments to super constructor */);
>>> this.{
>>> //per instance property definitions
>>> };
>>> }.prototype.{
>>> //instance properties defined on prototype
>>> }.constructor.{
>>> //class (ie, constructor) properties
>>> };
>>
>> I totally appreciate Allen's effort to build coherence around the
>> operator-to-be-named-curiously triangle.
>>
>> For me this form is confusing compared to a class-based language. A()
>> should construct A-s, A.foo() should be a method of A-s.
>> Prototypical classes should have a prototype as their super class.
>>
>> But here we have a .prototype defining instance properties
>
> I see instance properties being defined in their own this.{} block
>
>> I guess
>> every JS dev is puzzled by .prototype already.
>> Compared to a class
>> language, it seems like a hack. Do we really need it?
>
> I can't tell if this is sarcasm...
Not sarcasm. I am asserting that creating instances using a function
with special property for methods -- "prototype" -- places JavaScript
at a disadvantage. It's a contortion of syntax and vocabulary. Let's
not perpetuate this confusion.
> Ive long held that prototypes are the next evolutionary step up from classes
> - developers need to evolve now as well. Perhaps I've misunderstood your
> meaning?
I guess so, because my point is that the unimportant ".prototype"
('dot prototype') confuses the important 'prototype' in prototypical
inheritance.
jjb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
