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 1 of 2  [1] 2  Next page →

#25953 — ECMAScript and classes

ECMAScript and classes

It is sometimes said that "ECMAScript does not have classes". This
is misleading.

ECMAScript is a Turing-complete language that can implement
anything that any other Turing-complete language can implement,
though it could be slower and uglier.

C is another language that "does not have classes", yet the early
C++ compilers translated C++ programs into C programs that were
then compiled by a C compiler into programs that *implemented*
classes.

What ECMAScript and C don't have is full *support* for classes. In
C++, Java, and C# the programmer tells the compiler what each object
in the class should look like, then the compiler writes all the
tedious code that makes it work. This code includes ways for each
object in a class to access the functions (methods) shared by every 
member of the class.

As a useful byproduct it is difficult to alter an object's data and 
functions in a way that corrupts the intended working of the object.

In contrast, ECMAScript and C have some *support* for classes but 
most of the tedious code needed to *implement* a class has to be 
written by the Poor Old Programmer.

C has the dot operator and data and function pointers so that shared 
functions can be held in one place.

ECMAScript has those and also the 'new' operator. 'new' creates a 
new object and then connects it to the functions to be shared with
other objects. But all the object's data fields have to be coded by
the programmer.

As an inconvenient byproduct it is all too easy to alter an object's
data and functions in a way that corrupts the intended working of
the object. 

Alternatively, if an object's internal structure is to be changed 
after creation then it is not very useful to say it belongs to a 
'class'.

To sum up, C++, Java, and suchlike fully *support* classes whereas 
ECMAScript allows programmers to *implement* classes but provides 
less than full *support* for them.

  John

[toc] | [next] | [standalone]

#25955

Am 2014-10-21 um 11:49 schrieb John Harris:
>
> ECMAScript and classes
>
> It is sometimes said that "ECMAScript does not have classes". This
> is misleading.

[snip]

The problem is that *constructor functions* are frequently called 
"classes". Which they are clearly not.

Gregor

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

#25974

On Tue, 21 Oct 2014 12:25:41 +0200, Gregor Kofler
<usenet@gregorkofler.com> wrote:

>Am 2014-10-21 um 11:49 schrieb John Harris:
>>
>> ECMAScript and classes
>>
>> It is sometimes said that "ECMAScript does not have classes". This
>> is misleading.
>
>[snip]
>
>The problem is that *constructor functions* are frequently called 
>"classes". Which they are clearly not.

Very true. There's a lot of confusion and muddled thinking in this
area.

Unfortunately, the proposed update to the standard given in

<http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes>
has a terminology section with the definition : 

  "class: 
   The set of objects consisting of a constructor function and
   prototype object that is referenced by the function’s “prototype” 
   property."

This is even worse than the standard using "Reference" to mean an
object coupled with an identifier (and a marker in later editions).

  John

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

#25957

John Harris wrote:

> To sum up, C++, Java, and suchlike fully *support* classes whereas 
> ECMAScript allows programmers to *implement* classes but provides 
> less than full *support* for them.

It seems to be important to distinguish between the Ecma-262 editions.
Your notes seem to take into account only Ecma-262 Edition 3. Edition
5.1 (or maybe 5 already) introduced Object.seal()[1] which can be
applied to the prototype object. 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.

[1] <http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.8>
[2]
<http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes>
[3] <http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects>

-- 
Christoph M. Becker

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

#25967

Christoph M. Becker wrote:

> John Harris wrote:
>> To sum up, C++, Java, and suchlike fully *support* classes whereas
>> ECMAScript allows programmers to *implement* classes but provides
>> less than full *support* for them.
> 
> It seems to be important to distinguish between the Ecma-262 editions.
> Your notes seem to take into account only Ecma-262 Edition 3. Edition
> 5.1 (or maybe 5 already) introduced Object.seal()[1]

5 did, see ES 5.1 Annex F (which does not mention a change there).

> which can be applied to the prototype object. 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.

Also, implementations of the abandoned ECMAScript Edition 4 Working Draft do 
have native and support user-defined classes.  You can see that, for 
example, with Microsoft JScript .NET in ASP .NET, and ActionScript 2.0+ in 
Macromedia/Adobe Flash.  The Netscape implementation of that draft was 
versioned “JavaScript 2.0” (never released), and there was a reference  
implementation codenamed “Epimetheus”.

That Edition 6 might (I daresay, probably will) re-introduce classes in some 
way appears to be the result of the Harmony agreement:

<https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#25971

On 2014-10-21 19:27, Thomas 'PointedEars' Lahn wrote:
> That Edition 6 might (I daresay, probably will) re-introduce classes in some 
> way appears to be the result of the Harmony agreement:
> 
> <https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>

Very likely; it's been in the draft for ECMAScript 6 for a while now.
An unofficial provisional HTML version of the class specification can be
found here:
<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions>

Some examples and further details (slightly outdated, but close enough
to get a general idea):
<http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes>

I'm not actively following the ES6 specification process. Some of the
examples I've seen look like a whole new language. This will take some
getting used to... Interesting times.


- stefan

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

#25975

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> It seems to be important to distinguish between the Ecma-262 editions.
>> Your notes seem to take into account only Ecma-262 Edition 3. Edition
>> 5.1 (or maybe 5 already) introduced Object.seal()[1]
> 
> 5 did, see ES 5.1 Annex F (which does not mention a change there).

Thanks.  Indeed Object.seal() was already part of Edition 5.[1]

[1]
<http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262%205th%20edition%20December%202009.pdf>

-- 
Christoph M. Becker

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

#25977

On Tue, 21 Oct 2014 19:27:14 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>That Edition 6 might (I daresay, probably will) re-introduce classes in some 
>way appears to be the result of the Harmony agreement:
>
><https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>

Replace 
  "re-introduce classes" 
by 
  "re-introduce *support* for classes". 
But not full support it appears.

  John

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

#26076

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> That Edition 6 might (I daresay, probably will) re-introduce classes in
>> some way appears to be the result of the Harmony agreement:
>>
>> <https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>
> 
> Replace
>   "re-introduce classes"
> by
>   "re-introduce *support* for classes".

There is a “class” keyword (which was therefore a “future reserved word” 
until then [1]), and the parts of the code that it declares *are* classes in 
that language:

<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-functions-and-classes>

The classes of the ES 4 Draft [2], which was implemented by some in 
production quality [3][4], are different at least in the fact that built-in 
types are classes as well.

> But not full support it appears.

That depends on how you define “class”.  The same as it is unreasonable to 
define OOP solely by the features of OOP present in, e.g., Java, it is 
unreasonable to define “class” only as it is used elsewhere, and then deny 
the existence of “classes” or “full support for classes” in an (draft) 
Edition of ECMAScript.

[1] <http://ecma-international.org/ecma-262/5.1/#sec-7.6.1.2>
[2]  
<https://web.archive.org/web/20070711050228/http://www.mozilla.org/js/language/es4/core/classes.html>
[3] <http://msdn.microsoft.com/en-us/library/ms974588.aspx>
[4] <http://help.adobe.com/en_US/AS2LCR/Flash_10.0/00000728.html>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26081

On Sat, 01 Nov 2014 20:59:46 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> That Edition 6 might (I daresay, probably will) re-introduce classes in
>>> some way appears to be the result of the Harmony agreement:
>>>
>>> <https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>
>> 
>> Replace
>>   "re-introduce classes"
>> by
>>   "re-introduce *support* for classes".
>
>There is a “class” keyword (which was therefore a “future reserved word” 
>until then [1]), and the parts of the code that it declares *are* classes in 
>that language:

No, no, no! The source code is not a class : it is a class
*definition*. The difference between a class and its definition is
important and needs to be understood. 

You say of an object, aka instance, that it belongs to a certain class
and that it is described by a certain class definition.


><http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-functions-and-classes>
>
>The classes of the ES 4 Draft [2], which was implemented by some in 
>production quality [3][4], are different at least in the fact that built-in 
>types are classes as well.



>> But not full support it appears.
>
>That depends on how you define “class”.  The same as it is unreasonable to 
>define OOP solely by the features of OOP present in, e.g., Java, it is 
>unreasonable to define “class” only as it is used elsewhere, and then deny 
>the existence of “classes” or “full support for classes” in an (draft) 
>Edition of ECMAScript.

A language where class instances have no instance data is so
restrictive that I don't believe anyone would pay money to use it.
Therefore it seems to me that instance properties are a sine qua non
and not describing them in the class definition is clearly a lack of
support.

However, if you insist it is not a lack then neither is a lack of a
'class' keyword. A special comment such as /*** Class ***/ would do
instead. Therefore you must stop saying that ES5 and earlier do not
have classes.

  <snip>

  John

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

#26101

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> That Edition 6 might (I daresay, probably will) re-introduce classes in
>>>> some way appears to be the result of the Harmony agreement:
>>>>
>>>> <https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>
>>> 
>>> Replace
>>>   "re-introduce classes"
>>> by
>>>   "re-introduce *support* for classes".
>>
>> There is a “class” keyword (which was therefore a “future reserved word”
>> until then [1]), and the parts of the code that it declares *are* classes
>> in that language:
> 
> No, no, no! The source code is not a class : it is a class
> *definition*.

Tetrapilotomy.  At the latest, when the source code in question is compiled, 
or the class identifier is first used, the class definition results in the 
creation of a class.  It may even result in the creation of a class object.

> The difference between a class and its definition is
> important and needs to be understood.

Your logic is flawed.  A class definition defines a class, which implies 
existence of the concept of a class.
 
> You say of an object, aka instance, that it belongs to a certain class
> and that it is described by a certain class definition.

True, but irrelevant.

>>> But not full support it appears.
>>
>> That depends on how you define “class”.  The same as it is unreasonable 
>> to define OOP solely by the features of OOP present in, e.g., Java, it is
>> unreasonable to define “class” only as it is used elsewhere, and then 
>> deny the existence of “classes” or “full support for classes” in an
>> (draft) Edition of ECMAScript.
> 
> A language where class instances have no instance data is so
> restrictive that I don't believe anyone would pay money to use it.

What do you mean by “class instance” and “instance data”?

> Therefore it seems to me that instance properties are a sine qua non
> and not describing them in the class definition is clearly a lack of
> support.

If you mean “instance of a class” and “data/properties of an instance“, 
respectively, then /ex falso quodlibet/ applies.  How did you get the idea 
that those instances could not hold data/have properties?  And how did you 
get the idea that one would have to pay for using an implementation of 
ECMAScript?

> However, if you insist it is not a lack then neither is a lack of a
> 'class' keyword. A special comment such as /*** Class ***/ would do
> instead. Therefore you must stop saying that ES5 and earlier do not
> have classes.

Although programming languages are designed for people and their identifiers 
are usually semantic, it is true that my argument does not hold that a 
“class” keyword in the grammar of a programming language implies support for 
classes there.  However, that this keyword is listed under the heading 
“Classes” of a normative section of a Specification or documentation for 
that language does.

Therefore, it is correct to say today that there is a possible future 
Edition of ECMAScript that is going to support classes, and there are 
several implementations of a past draft of an Edition of ECMAScript that do 
support classes.  I have referred to that past draft and implementation 
documentation before; the relevant section of the draft for the future 
Edition is available at

<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions>

Those are the specification of class definitions for classes in ECMAScript 
(implementations); they may be different from what is understood as a 
“class” elsewhere, but that is irrelevant.  Therefore, it is illogical to 
deny the existence and support of classes in the former languages.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26104

On Sat, 08 Nov 2014 19:11:11 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John Harris wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> That Edition 6 might (I daresay, probably will) re-introduce classes in
>>>>> some way appears to be the result of the Harmony agreement:
>>>>>
>>>>> <https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html>
>>>> 
>>>> Replace
>>>>   "re-introduce classes"
>>>> by
>>>>   "re-introduce *support* for classes".
>>>
>>> There is a ?class? keyword (which was therefore a ?future reserved word?
>>> until then [1]), and the parts of the code that it declares *are* classes
>>> in that language:
>> 
>> No, no, no! The source code is not a class : it is a class
>> *definition*.

>Tetrapilotomy.  

A Google search shows it's usually spelt tetrapyloctomy. The word is
not in the Oxford Dictionary of English, with either spelling; nor is
it in the New Oxford American Dictionary. A sensible person would say
'hair-splitting' instead when addressing an international audience.

As to hair-splitting, I invite Thomas to comment on the famous
statement "Ceci n'est pas une pipe". Also to explain why the
description of an angry bear is less dangerous than the thing
described.


>At the latest, when the source code in question is compiled, 
>or the class identifier is first used, the class definition results in the 
>creation of a class.  It may even result in the creation of a class object.

The class definition results in the creation of the code needed by
programmers who want to create objects belonging to the class. This
result happens because the ES 6 draft standard says it must.


>> The difference between a class and its definition is
>> important and needs to be understood.
>
>Your logic is flawed.  A class definition defines a class, which implies 
>existence of the concept of a class.

Mystical mumbo jumbo.


>> You say of an object, aka instance, that it belongs to a certain class
>> and that it is described by a certain class definition.
>
>True, but irrelevant.

Very relevant if you don't understand what a class is.


>>>> But not full support it appears.
>>>
>>> That depends on how you define ?class?.  The same as it is unreasonable 
>>> to define OOP solely by the features of OOP present in, e.g., Java, it is
>>> unreasonable to define ?class? only as it is used elsewhere, and then 
>>> deny the existence of ?classes? or ?full support for classes? in an
>>> (draft) Edition of ECMAScript.
>> 
>> A language where class instances have no instance data is so
>> restrictive that I don't believe anyone would pay money to use it.
>
>What do you mean by “class instance” and “instance data”?

What anyone else talking in English about an OO language would mean.


>> Therefore it seems to me that instance properties are a sine qua non
>> and not describing them in the class definition is clearly a lack of
>> support.
>
>If you mean “instance of a class” and “data/properties of an instance“, 
>respectively, then 

>/ex falso quodlibet/

This is an English language group. If you want to say there's a
contradiction you should say so, and hint at where you think the
contradiction is.


>applies.  How did you get the idea 
>that those instances could not hold data/have properties?  

An ES 6 class definition either says what properties each instance
object must have, or it doesn't. In the first case there are no
instance properties and the objects have little use; in the second
case there is a clear lack of full support for classes.


>And how did you 
>get the idea that one would have to pay for using an implementation of 
>ECMAScript?

As I never said that, it's not a question that has an answer.

I said that objects defined to never have any own-properties have
little or no value.


>> However, if you insist it is not a lack then neither is a lack of a
>> 'class' keyword. A special comment such as /*** Class ***/ would do
>> instead. Therefore you must stop saying that ES5 and earlier do not
>> have classes.
>
>Although programming languages are designed for people and their identifiers 
>are usually semantic, it is true that my argument does not hold that a 
>“class” keyword in the grammar of a programming language implies support for 
>classes there.  However, that this keyword is listed under the heading 
>“Classes” of a normative section of a Specification or documentation for 
>that language does.
>
>Therefore, it is correct to say today that there is a possible future 
>Edition of ECMAScript that is going to support classes, and there are 
>several implementations of a past draft of an Edition of ECMAScript that do 
>support classes.  I have referred to that past draft and implementation 
>documentation before; the relevant section of the draft for the future 
>Edition is available at
>
><http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions>
>
>Those are the specification of class definitions for classes in ECMAScript 
>(implementations); they may be different from what is understood as a 
>“class” elsewhere, but that is irrelevant.  Therefore, it is illogical to 
>deny the existence and support of classes in the former languages.

As I have said that there's been some support for classes in all
editions of ECMAScript it would indeed be illogical to deny it.

What you have failed to notice is that I said that although draft 6
has more support it is still not full support as it lacks an obvious
feature.

Features needed to *implement* classes have, of course, been fully
present in all editions.

  John

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

#26105

In article <dsj16apqju2hj2e02tvb9von9ukghmr0uk@4ax.com>, John Harris
<niam@jghnorth.org.uk.invalid> wrote:

> On Sat, 08 Nov 2014 19:11:11 +0100, Thomas 'PointyHead' Lahn
> <PointedEars@web.de> wrote:

> >Tetrapilotomy.  
> 
> A Google search shows it's usually spelt tetrapyloctomy. The word is
> not in the Oxford Dictionary of English, with either spelling; nor is
> it in the New Oxford American Dictionary. A sensible person would say
> 'hair-splitting' instead when addressing an international audience.
> 
> As to hair-splitting, I invite Thomas to comment on the famous
> statement "Ceci n'est pas une pipe". Also to explain why the
> description of an angry bear is less dangerous than the thing
> described.

PointyHead is the world's expert on hair-splitting and counting angels
on pinheads. So, as I suppose, you are hoping to make him deviate from
this straight and narrow path, you must be an optimist indeed.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

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

#26106

John Harris wrote:

> On Sat, 08 Nov 2014 19:11:11 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>> John Harris wrote:
>>
>>> Therefore it seems to me that instance properties are a sine qua non
                                                            ^^^^^^^^^^^^
>>> and not describing them in the class definition is clearly a lack of
>>> support.
>>
>> If you mean “instance of a class” and “data/properties of an instance“, 
>> respectively, then 
> 
>> /ex falso quodlibet/
> 
> This is an English language group. 

That *might* be debatable, but at least when you are making this claim,
you should consider avoiding non English phrases as well.


>> And how did you 
>> get the idea that one would have to pay for using an implementation of 
>> ECMAScript?
> 
> As I never said that, it's not a question that has an answer.

In <news:td9f5a9f08ameij4n0610eg187jj41suke@4ax.com> you have said:

| A language where class instances have no instance data is so
| restrictive that I don't believe anyone would pay money to use it.

-- 
Christoph M. Becker

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

#26109

On Mon, 10 Nov 2014 18:02:31 +0100, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> On Sat, 08 Nov 2014 19:11:11 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>> 
>>> John Harris wrote:
>>>
>>>> Therefore it seems to me that instance properties are a sine qua non
>                                                            ^^^^^^^^^^^^
>>>> and not describing them in the class definition is clearly a lack of
>>>> support.
>>>
>>> If you mean “instance of a class” and “data/properties of an instance“, 
>>> respectively, then 
>> 
>>> /ex falso quodlibet/
>> 
>> This is an English language group. 
>
>That *might* be debatable, but at least when you are making this claim,
>you should consider avoiding non English phrases as well.

That was deliberate, aimed at Thomas. I was careful to use a phrase
that is well known, at least in Britain.


>>> And how did you 
>>> get the idea that one would have to pay for using an implementation of 
>>> ECMAScript?
>> 
>> As I never said that, it's not a question that has an answer.
>
>In <news:td9f5a9f08ameij4n0610eg187jj41suke@4ax.com> you have said:
>
>| A language where class instances have no instance data is so
>| restrictive that I don't believe anyone would pay money to use it.

Why do you think that I'm talking about ECMAScript rather than a
hypothetical and very useless language?

  John

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

#26132

John Harris wrote:

> On Mon, 10 Nov 2014 18:02:31 +0100, "Christoph M. Becker"
> <cmbecker69@arcor.de> wrote:
> 
>> In <news:td9f5a9f08ameij4n0610eg187jj41suke@4ax.com> you have said:
>>
>> | A language where class instances have no instance data is so
>> | restrictive that I don't believe anyone would pay money to use it.
> 
> Why do you think that I'm talking about ECMAScript rather than a
> hypothetical and very useless language?

Because you had responded to Thomas' statement:

| That depends on how you define “class”.  The same as it is
| unreasonable to define OOP solely by the features of OOP present in,
| e.g., Java, it is unreasonable to define “class” only as it is used
| elsewhere, and then deny the existence of “classes” or “full support
| for classes” in an (draft) Edition of ECMAScript.

-- 
Christoph M. Becker

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

#26134

On Thu, 13 Nov 2014 17:48:04 +0100, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> On Mon, 10 Nov 2014 18:02:31 +0100, "Christoph M. Becker"
>> <cmbecker69@arcor.de> wrote:
>> 
>>> In <news:td9f5a9f08ameij4n0610eg187jj41suke@4ax.com> you have said:
>>>
>>> | A language where class instances have no instance data is so
>>> | restrictive that I don't believe anyone would pay money to use it.
>> 
>> Why do you think that I'm talking about ECMAScript rather than a
>> hypothetical and very useless language?
>
>Because you had responded to Thomas' statement:
>
>| That depends on how you define “class”.  The same as it is
>| unreasonable to define OOP solely by the features of OOP present in,
>| e.g., Java, it is unreasonable to define “class” only as it is used
>| elsewhere, and then deny the existence of “classes” or “full support
>| for classes” in an (draft) Edition of ECMAScript.

All right : it can be misread. Replace "A language" by "Any language".
Better still, replace it by "Any hypothetical language".

  John

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

#26107

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tetrapilotomy.
> 
> A Google search shows it's usually spelt tetrapyloctomy.

And if a Google search shows that the moon mostly consists of green cheese, 
do you believe it, too?

> The word is not in the Oxford Dictionary of English, with either spelling;
> nor is it in the New Oxford American Dictionary. A sensible person would
> say 'hair-splitting' instead when addressing an international audience.

A “sensible person”, by that measure, would also not write “sine qua non”.
 
> As to hair-splitting, I invite Thomas […]

Have you noticed that you revert to talking to/about others (me in 
particular) in the third person whenever your arguments fail to convince 
them (me) – because your arguments are fallacious –, or when you are simply 
out of (good) arguments (if you had any)?  That is driven by another, very 
old fallacy that can be found in the group of red herring fallacies.  And I 
refuse to make free time for it.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26112

On Mon, 10 Nov 2014 23:03:40 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Tetrapilotomy.
>> 
>> A Google search shows it's usually spelt tetrapyloctomy.

>And if a Google search shows that the moon mostly consists of green cheese, 
>do you believe it, too?

Dictionaries record what people actually write, and a Google result is
initial evidence of that.


>> The word is not in the Oxford Dictionary of English, with either spelling;
>> nor is it in the New Oxford American Dictionary. A sensible person would
>> say 'hair-splitting' instead when addressing an international audience.
>
>A “sensible person”, by that measure, would also not write “sine qua non”.

I'm glad to see that someone disapproves of Latin phrases, especially
the less well known phrases.


>> As to hair-splitting, I invite Thomas […]
>
>Have you noticed that you revert to talking to/about others (me in 
>particular) in the third person 

Several people have stated that Usenet is not e-mail. When addressing
a remark towards or about a particular person it is necessary to
identify that person. Any other remarks are addressed to everyone.

It doesn't help that 'you' is both singular and plural, so "Have you
noticed" is ambiguous.


>whenever your arguments fail to convince 
>them (me) – because your arguments are fallacious –, or when you are simply 
>out of (good) arguments (if you had any)?  That is driven by another, very 
>old fallacy that can be found in the group of red herring fallacies.  And I 
>refuse to make free time for it.

Have you (plural) noticed that Thomas often ends up huffing and
puffing when there is a danger of recognising that he was too dogmatic
or plain wrong, usually with accompanying abuse.

  John

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

#25976

On Tue, 21 Oct 2014 13:27:38 +0200, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> To sum up, C++, Java, and suchlike fully *support* classes whereas 
>> ECMAScript allows programmers to *implement* classes but provides 
>> less than full *support* for them.
>
>It seems to be important to distinguish between the Ecma-262 editions.
>Your notes seem to take into account only Ecma-262 Edition 3. 

This is the problem for the web designer. Does he tell the
shareholders their company can sell only to people using the latest
whizzo browser; or does he write duplicate code for old and new
browsers; or does he write using just what's common to old and new?

How much does it cost to get reliable market research telling them
which browsers their intended customers use?


>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. All of which has to done by the Poor Old
Programmer, of course. But you do this only if you don't trust the
people who will be using the code, or you don't know who they might
be.


>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.
Occasionally this will be inconvenient. And it requires the Poor Old
Programmer to write the code inserting instance properties into a new
object.

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

  John

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web