Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #25953 > unrolled thread

ECMAScript and classes

Back to article view | Back to comp.lang.javascript

Contents

  ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-21 10:49 +0100
    Re: ECMAScript and classes Gregor Kofler <usenet@gregorkofler.com> - 2014-10-21 12:25 +0200
      Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-23 11:34 +0100
    Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-10-21 13:27 +0200
      Re: ECMAScript and classes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-21 19:27 +0200
        Re: ECMAScript and classes Stefan Weiss <krewecherl@gmail.com> - 2014-10-22 00:15 +0200
        Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-10-23 14:45 +0200
        Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-23 15:12 +0100
          Re: ECMAScript and classes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-01 20:59 +0100
            Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-03 15:56 +0000
              Re: ECMAScript and classes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-08 19:11 +0100
                Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-10 14:48 +0000
                  Re: ECMAScript and classes Tim Streater <timstreater@greenbee.net> - 2014-11-10 15:54 +0000
                  Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-10 18:02 +0100
                    Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-11 11:08 +0000
                      Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 17:48 +0100
                        Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-13 20:32 +0000
                  Re: ECMAScript and classes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-10 23:03 +0100
                    Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-11 17:03 +0000
      Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-23 14:58 +0100
        Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-10-23 18:37 +0200
          Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-24 11:30 +0100
            Re: ECMAScript and classes "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-10-24 19:45 +0200
              Re: ECMAScript and classes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-26 10:43 +0000

Page 2 of 2 — ← Prev page 1 [2]

#25978

John Harris wrote:

> On Tue, 21 Oct 2014 13:27:38 +0200, "Christoph M. Becker"
> <cmbecker69@arcor.de> wrote:
> 
>> Edition
>> 5.1 (or maybe 5 already) introduced Object.seal()[1] which can be
>> applied to the prototype object. 
> 
> It wouldn't be just the prototype object. It would be all the
> user-defined objects in the prototype chain and each class instance
> object as it is created. 

Usually you wouldn't seal the class instances, though, but rather
prevent their extension and maybe remove the configurable attribute on
the individual properties.

> All of which has to done by the Poor Old
> Programmer, of course.

The "Poor Old Programmer" could, however, write a function that does all
this for him.

>> Ecma-262 Edition 6 might introduce
>> "maximally minimal" classes[2] and private name objects[3] which would
>> provide better support for classes in the classical sense.
>   <snip>
> 
> The current draft ES6 allows only one constructor function per class.

This restriction applies to several object-oriented programming
languages with classical inheritance.

> So, ES6 will likely still only provide partial *support* for classes,
> while still allowing full *implementation* of classes as before.

What would be full *support* for classes.  Isn't multiple inheritance an
important concept, for instance, which is only supported by very few
languages?  What about multiple dispatch?

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#25980

On Thu, 23 Oct 2014 18:37:40 +0200, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> On Tue, 21 Oct 2014 13:27:38 +0200, "Christoph M. Becker"
>> <cmbecker69@arcor.de> wrote:
>> 
>>> Edition
>>> 5.1 (or maybe 5 already) introduced Object.seal()[1] which can be
>>> applied to the prototype object. 
>> 
>> It wouldn't be just the prototype object. It would be all the
>> user-defined objects in the prototype chain and each class instance
>> object as it is created. 
>
>Usually you wouldn't seal the class instances, though, but rather
>prevent their extension and maybe remove the configurable attribute on
>the individual properties.

But that's what seal does!


>> All of which has to done by the Poor Old
>> Programmer, of course.
>
>The "Poor Old Programmer" could, however, write a function that does all
>this for him.

And then remember to write the code in the constructor to call the
function.


>>> Ecma-262 Edition 6 might introduce
>>> "maximally minimal" classes[2] and private name objects[3] which would
>>> provide better support for classes in the classical sense.
>>   <snip>
>> 
>> The current draft ES6 allows only one constructor function per class.
>
>This restriction applies to several object-oriented programming
>languages with classical inheritance.

Multiple inheritance in ECMAScript terms would change the prototype
chain into a prototype tree. Not all that difficult to do in
ECMAScript I suspect but very unlikely!

Multiple constructors, on the other hand, give you a choice of
parameters. You can already have  new Thing()  and  new Thing(3,4)  by
putting code in the constructor to look at the argument list and then
replacing missing arguments by default values : oh look, multiple
constructors.

Occasionally, though, you would like the same number of parameters of
the same type with different meanings. E.g A new complex number given
the (x,y) values or the (modulus,angle) values. 


>> So, ES6 will likely still only provide partial *support* for classes,
>> while still allowing full *implementation* of classes as before.
>
>What would be full *support* for classes.  Isn't multiple inheritance an
>important concept, for instance, which is only supported by very few
>languages?  What about multiple dispatch?

Full support for classes needn't include inheritance : you can have
classes with or without inheritance and I'm concentrating on classes.

Full support would include creating the new object's properties,
presumably holding a default value such as undefined. This would also
mean that the property names are listed in the class description, as
they should be.

And wouldn't it be nice if you could write x instead of this.x inside
methods.

  John

[toc] | [prev] | [next] | [standalone]

#25983

John Harris wrote:

> On Thu, 23 Oct 2014 18:37:40 +0200, "Christoph M. Becker"
> <cmbecker69@arcor.de> wrote:
> 
>> Usually you wouldn't seal the class instances, though, but rather
>> prevent their extension and maybe remove the configurable attribute on
>> the individual properties.
> 
> But that's what seal does!

Of course, you're right.

>> The "Poor Old Programmer" could, however, write a function that does all
>> this for him.
> 
> And then remember to write the code in the constructor to call the
> function.

No, I meant something like

  function defineClass(...) {...}

There are numerous variants available.

> Multiple constructors, on the other hand, give you a choice of
> parameters. You can already have  new Thing()  and  new Thing(3,4)  by
> putting code in the constructor to look at the argument list and then
> replacing missing arguments by default values : oh look, multiple
> constructors.

Well, as ECMAScript function signatures are quite flexible, you don't
necessarily need multiple constructors, and you won't have any improved
type safety by having them.

> Occasionally, though, you would like the same number of parameters of
> the same type with different meanings. E.g A new complex number given
> the (x,y) values or the (modulus,angle) values. 

You could create functions as methods of the constructor ("static
methods"), each of them converting the arguments as needed and calling
the constructor with the new operator, for instance:

  Complex.createCartesian = function (x, y) {...}
  Complex.createPolar = function (modulus, angle) {...}

> Full support would include creating the new object's properties,
> presumably holding a default value such as undefined. This would also
> mean that the property names are listed in the class description, as
> they should be.

I agree that this would be nicer, but you could use a class defining
function to have a similar notation.

> And wouldn't it be nice if you could write x instead of this.x inside
> methods.

AFAIK, the need to qualify instance properties is quite common in
"dynamic" languages.  And at least it has also some advantages.

Note, that I do not argue that support for classes in ECMAScript
shouldn't be improved, but rather that one has to take what he gets, and
that there are viable ways to deal with the limitations (at least in ES 5).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#25987

On Fri, 24 Oct 2014 19:45:09 +0200, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

  <snip>
>Note, that I do not argue that support for classes in ECMAScript
>shouldn't be improved, but rather that one has to take what he gets, and
>that there are viable ways to deal with the limitations (at least in ES 5).

It looks as though we both agree that classes can be implemented in ES
5.1, and if you don't need the luxury of Object.seal they can be
implemented in ES 3.

What the new features in ES 6 do is to remind programmers using them
that they're designing a class of objects, not just individual
objects.

The new features also have the happy side effect of causing people to
implement inheritance the straightforward ECMAScript way instead of
one of the messy and complicated ways that are so popular.

  John

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web