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

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

Can somebody explain this to me

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

Contents

  Can somebody explain this to me "Tony Johansson" <johansson.andersson@telia.com> - 2015-01-06 00:48 +0100
    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-06 01:40 +0100
      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-06 16:01 +0000
        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-06 17:26 +0100
          Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com> - 2015-01-07 00:45 -0200
            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 04:35 +0100
              Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-07 16:15 -0200
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 21:20 +0100
                  Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 00:00 +0100
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 00:09 +0100
                      Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 10:53 +0100
                        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 16:17 +0100
                          Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 17:04 +0100
                            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 19:02 +0100
          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-07 15:37 +0000
            Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-07 17:01 +0100
              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:43 +0000
                Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 13:16 +0100
            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 16:43 +0100
              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-09 20:16 +0000
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-09 22:11 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-10 16:58 +0000
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-11 12:41 +0100
                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-12 15:46 +0000
                        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-12 18:01 +0100
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-13 10:38 +0000
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-14 16:06 +0000
                Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-21 13:00 -0800
                  Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com> - 2015-01-21 20:53 -0200
                    Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-22 11:43 +0000
                      Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-22 10:20 -0200
                        Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-23 19:42 +0000
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-28 18:14 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-22 11:39 +0000
                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-22 13:27 +0100
                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-23 14:36 +0000
                        Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-23 08:51 -0800
                          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-23 23:17 +0100
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-24 16:42 +0000
                            Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-24 15:35 -0800
                              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-25 11:08 +0000
                                Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-26 08:33 -0800
                                Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-27 14:10 +0100
                                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-28 15:50 +0000
                                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-28 18:26 +0100
                                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:29 +0000
                                        Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-31 00:37 +0100
                                    Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-28 13:30 -0800
                                      Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-28 22:40 +0100
                                        Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:32 +0000
                                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:23 +0000
                                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 11:04 +0000
                              Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-26 08:21 -0800
                                Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-26 11:10 -0800
                    Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-22 06:36 -0800
        Re: Can somebody explain this to me Tim Streater <timstreater@greenbee.net> - 2015-01-06 17:34 +0000
          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-06 19:03 +0100
            Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-07 15:07 +0000
              Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-07 16:41 +0100
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 17:22 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:36 +0000
                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 13:36 +0100
                      Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 17:54 +0100
                        Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 19:48 +0100
                          Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 22:09 +0100
                        Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-08 18:22 -0200
                          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 22:13 +0100
                          Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 22:25 +0100
                Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:25 +0000
                  Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 11:33 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#26522

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> John Harris wrote:
>   <snip>
>>>>> No; here is the class's constructor function.
>>>> Utter nonsense.
>>> It *is* a constructor function.
>> But _not_ a class’s.
> 
> "Utter" implies all of it is wrong.

Adding “class’s” makes it all wrong.

That said, in this context “utter” does not carry that meaning in my book.  
I understand it to be the kind of nonsense that if the author had put a 
little more thought into it, they would have realized by themselves that it 
is nonsense (of the kind that is *not* humorous) and would have refrained 
from making the statement.  I do not think I am alone there.

>> And one might find out then that the constructed objects have not much if
>> anything in common even before the caller starts to augment them. 
>> Therefore it is just a constructor (function), not a "class’s constructor
>> (function)",
>> and certainly it is _not_ a "class".  Generally speaking, a class of
>> objects need to have something, if not most of their properties, in
>> common, hence the term in computer science too.
> 
> It's a funny constructor that doesn't create equivalent objects.

Quite normal in ECMAScript, though.  Because a constructor in ECMAScript is 
_not_ (like) a class declaration/definition, some objects thus created can 
have some properties (that includes methods) that others have not:

  function C (a)
  {
    if (a)
    {
      this.a = a;
    }
  }

There is a well known precedent, although a host object: ActiveXObject.  
Depending on the arguments of the constructor call, an entirely different 
object will be constructed.

> (Same property names, same prototype chain).

Not necessarily.  As for the latter, a constructor can return a value.
If that value is of the Object type, the referred object is returned instead 
of the “this” value.  AISB, I am using this to return a Proxy instance if 
possible.

In fact, because a constructor defined by function declaration can virtually 
replace itself, the constructed objects need not have to have the same 
constructor even if the constructor calls are byte-by-byte-equal source 
code.

Bottom line: A constructor in ECMAScript is not like a constructor of a 
class; it is more like a(n object) factory.  In fact, in more recent 
implementations it takes only one line, three at most, so that a constructor 
can be called as a function, like a factory, and still work as if it was 
called as a constructor:

  function C (a, b)
  {
    if (!(this instanceof C)) { return new C(a, b); }

    /* … */
  }

I have posted this here before.

[Because this is so common a pattern, I have created, with a little help 
from this newsgroup, Function.prototype.construct() and .construct2() with 
which you can call any Function instance as constructor without using “new” 
explicitly.  This allows the effective argument list to be of arbitrary 
length, passed as an array-like object:

  function C (a, b)
  {
    if (!(this instanceof C)) { return C.construct(arguments); }

    /* … */
  }
]

> In your words, the created objects have something in common.

Not necessarily.

> If the program goes on to make arbitrary changes to the properties
> held then obviously the program is not taking advantage of their
> initial equivalence, and so not treating them as members of a class.

I have already pointed out that the caller need not modify the constructed 
objects for differences between the instances.

>>> It would be advantageous if that were written down in the
>>> program's documentation before coding, […]
>>
>>It would be advantageous if you got yourself a minimum clue before you
>>post again.
> 
> There are dozens, if not hundreds, of books on how to organise an
> enterprise-scale software project. You have now declared all these
> books to be rubbish.

No, I declared what you wrote on ECMAScript “rubbish”, in your wording.

>   <snip>
>>Red herring.  Your statement is somewhat interesting (though off-topic),
>>but entirely irrelevant to the question at hand, which is “Should one
>>refer to a constructor as a "class" (as you prefer to)?”.
> 
> I *never* refer to a constructor as a "class".

Then you should not have objected in the first place because that was the 
question at hand.
 
> A class is a class of objects, not their constructor function(s), nor
> their definition (explicit or implicit).

But I followed up on an OP that claimed something else.  You objected to 
what I wrote there.

>>I think that sufficient
>>arguments, authoritative evidence indeed, has been presented by more than
>>one person here to conclude that one should not.
> 
>>So everyone’s life – not least that of newcomers seeking clarity here –
>>would be easier if you *please* stop doing that.
> 
> From the earliest JavaScript onward the language(s) have had all the
> facilities needed to implement classes.

Doubtful; you will have to prove that.  And which kind of classes?  C++’s?  
Java’s?  Something else’s?

I can certainly agree that it is possible to use JavaScript, all major 
ECMAScript implementations really, to implement some features of class-based 
inheritance; I am doing that myself.

But what matters is: It/they did not *have* classes until now (if we ignore 
the ECMAScript Edition 4 draft and its implementations).  The authoritative 
documentation of the respective programming language does not feature that 
term; in fact, it explicitly says that there are no classes in either 
language, and rightly so.  To claim otherwise is misleading.  It is you who 
made the claim, and *that* was to which I, among others, objected.

-- 
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]

#26532

On Fri, 09 Jan 2015 22:11:48 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John Harris wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> John Harris wrote:


  <snip> 
>> It's a funny constructor that doesn't create equivalent objects.
>
>Quite normal in ECMAScript, though.
  <snip>
>> (Same property names, same prototype chain).
>
>Not necessarily. 
  <snip>
>> In your words, the created objects have something in common.
>
>Not necessarily.

All right, I'll extend my words : 
  If that's what the programmer wants then in your words the 
  created objects have something in common.


>> If the program goes on to make arbitrary changes to the properties
>> held then obviously the program is not taking advantage of their
>> initial equivalence, and so not treating them as members of a class.
>
>I have already pointed out that the caller need not modify the constructed 
>objects for differences between the instances.
  <snip> 

All right, the constructor can also play games when the caller has
delegated part of the job to the constructor.


>> I *never* refer to a constructor as a "class".
>
>Then you should not have objected in the first place because that was the 
>question at hand.

No it wasn't. You objected to the word 'class' in the phrase 'class
definition'. 


>> A class is a class of objects, not their constructor function(s), nor
>> their definition (explicit or implicit).
>
>But I followed up on an OP that claimed something else.  You objected to 
>what I wrote there.
  <snip>

What do you mean?


>>>I think that sufficient
>>>arguments, authoritative evidence indeed, has been presented by more than
>>>one person here to conclude that one should not.
>> 
>>>So everyone?s life ? not least that of newcomers seeking clarity here ?
>>>would be easier if you *please* stop doing that.
>> 
>> From the earliest JavaScript onward the language(s) have had all the
>> facilities needed to implement classes.
>
>Doubtful; you will have to prove that.  And which kind of classes?  C++’s?  
>Java’s?  Something else’s?
  <snip>

Look at the (draft) specification for ES6 class declarations and ask
yourself which features the compiler must use that aren't in ES2 to
ES5.1.


>I can certainly agree that it is possible to use JavaScript, all major 
>ECMAScript implementations really, to implement some features of class-based 
>inheritance; I am doing that myself.
>
>But what matters is: It/they did not *have* classes until now (if we ignore 
>the ECMAScript Edition 4 draft and its implementations).  The authoritative 
>documentation of the respective programming language does not feature that 
>term; in fact, it explicitly says that there are no classes in either 
>language, and rightly so.  To claim otherwise is misleading.  It is you who 
>made the claim, and *that* was to which I, among others, objected.

If people can understand that ES2 to ES5.1 contain all the facilities
needed to implement classes then they will be at an advantage when ES6
arrives. They will understand that in ES6 the compiler does the work
for you. They will not be confused by what is no doubt going to be a
lot of misleading writing, some of it pure mysticism.


  John

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

#26539

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> John Harris wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> John Harris wrote:
>>> I *never* refer to a constructor as a "class".
>> Then you should not have objected in the first place because that was the
>> question at hand.
> 
> No it wasn't. You objected to the word 'class' in the phrase 'class
> definition'.

I objected to the term “class definition” in the way in which it was used by 
the OP.  Then I objected to your use of “class’s constructor function”.

>>> A class is a class of objects, not their constructor function(s), nor
>>> their definition (explicit or implicit).
>>
>> But I followed up on an OP that claimed something else.  You objected to
>> what I wrote there.
>   <snip>
> 
> What do you mean?

The OP wrote:

|        function P(foo) //Here is the class definition
|        {
|            this.foo = foo;
|            // implicit return av "this" i den fall då P anropas som 
| konstruktor
| 
|        }
| 
| […]
| I mean if I add this piece of code into the class definition […]
| […]
|        function P(foo) //Here is the class definition

I followed up with:

| > I mean if I add this piece of code into the class definition […]
| 
| There are no classes in this case; prototype-based inheritance is used.
| 
| […]
| >        function P(foo) //Here is the class definition
| 
| No, there is the declaration of a function named “P” that can be called as 
| a constructor.  This also means that a Function instance (an object) is 
| being created that can be referred to by “P”.

You objected to that with:
 
| > There are no classes in this case;
| 
| Not true. See an earlier thread.
| 
| […]
| >>        function P(foo) //Here is the class definition
|   <snip>
| 
| No; here is the class's constructor function. The class's definition
| has to be deduced from the code, which is presumably why some people
| say ECMAScript, up to v5 at least, has no classes.

(Note how you misquoted.)

>>>> I think that sufficient
>>>> arguments, authoritative evidence indeed, has been presented by more
>>>> than one person here to conclude that one should not.
>>>> So everyone?s life ? not least that of newcomers seeking clarity here ?
>>>> would be easier if you *please* stop doing that.
>>> From the earliest JavaScript onward the language(s) have had all the
>>> facilities needed to implement classes.
>> Doubtful; you will have to prove that.  And which kind of classes?  
>> C++’s? Java’s?  Something else’s?
>   <snip>
> 
> Look at the (draft) specification for ES6 class declarations and ask
> yourself which features the compiler must use that aren't in ES2 to
> ES5.1.

You are trying to shift the burden of proof.

Besides, “ES2 to ES5.1” includes the ES4 draft.  And why do you exclude ES1?
 
>> I can certainly agree that it is possible to use JavaScript, all major
>> ECMAScript implementations really, to implement some features of
>> class-based inheritance; I am doing that myself.
>>
>> But what matters is: It/they did not *have* classes until now (if we
>> ignore the ECMAScript Edition 4 draft and its implementations).  The
>> authoritative documentation of the respective programming language does
>> not feature that term; in fact, it explicitly says that there are no
>> classes in either language, and rightly so.  To claim otherwise is
>> misleading.  It is you who made the claim, and *that* was to which I, 
>> among others, objected.
> 
> If people can understand that ES2 to ES5.1 contain all the facilities
> needed to implement classes

Your proof of that is pending.

> then they will be at an advantage when ES6 arrives.

No, because the concept of classes that is going to be in ES6 has nothing to 
do with that, and there are previous implementations which did have a 
concept of classes that were different from both those concepts *and* the 
concept of a class in class-based inheritance.

-- 
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]

#26556

On Sun, 11 Jan 2015 12:41 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:


  <snip> 
>> If people can understand that ES2 to ES5.1 contain all the facilities
>> needed to implement classes
>
>Your proof of that is pending.

We can only go by the current draft of the ES6 standard, dated 2014
Dec 24 at the time of writing. Obviously, it could be totally
different when the candidate standard is approved.

The draft says that this is what the compiler must do to process a
class declaration :-

a) Create a new prototype object and form a prototype chain, as
required : without inheriting; with inheriting; with no standard
object prototype at the end of the chain.

There is nothing new about this (except the last option which is not
available in ES3).

b) Create a constructor function object, as required : by compiling
the given function body; by creating a default function if no body is
given.

There is nothing new about this.

c) Create method function objects by compiling the given function
bodies and make them properties of the prototype object that is at the
head of the prototype chain.

There is nothing new about this.

d) Make the constructor visible as required : globally for a global
class; locally for a local class.

There is nothing new about this.


See <http://people.mozilla.org/~jorendorff/es6-draft.html>

Quod Erat Demonstrandum


>> then they will be at an advantage when ES6 arrives.
>
>No, because the concept of classes that is going to be in ES6 has nothing to 
>do with that, and there are previous implementations which did have a 
>concept of classes that were different from both those concepts *and* the 
>concept of a class in class-based inheritance.

Have you been looking at a different draft?

Or have you been reading blogs full of mysticism and twaddle?


  John

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

#26558

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>   <snip>
>>> If people can understand that ES2 to ES5.1 contain all the facilities
>>> needed to implement classes
>> Your proof of that is pending.
> 
> We can only go by the current draft of the ES6 standard, dated 2014
> Dec 24 at the time of writing. Obviously, it could be totally
> different when the candidate standard is approved. […]

The proof that is required of you is that “ES2 to ES5.1” (where you did not 
consider the ES4 draft that does have classes, and for a still unexplained 
reason excluded ES1) “contain all the facilities needed to implement 
classes”.  Because *that* is what you claimed.

In order to provide that proof you would need to pick at least one real-
world flavor of class-based inheritance and then show that *all* of its 
features can be implemented with a conforming implementation of “ES2 to 
ES5.1” (excluding the ES4 draft).  You would then have proven that it is 
possible to *fully* implement all the *selected* flavors of class-based 
inheritance with the aforementioned ECMAScript implementations.

Can you do that?

Only *after* you have done that it makes sense to discuss whether your 
second claim, that using the term “class” as you prefer to use it *now* is 
going to help with using ES6’s classes (as they are currently specified in 
the working draft), has any basis in reality.

-- 
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]

#26567

On Mon, 12 Jan 2015 18:01:51 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>   <snip>
>>>> If people can understand that ES2 to ES5.1 contain all the facilities
>>>> needed to implement classes
>>> Your proof of that is pending.
>> 
>> We can only go by the current draft of the ES6 standard, dated 2014
>> Dec 24 at the time of writing. Obviously, it could be totally
>> different when the candidate standard is approved. […]
>
>The proof that is required of you is that “ES2 to ES5.1” (where you did not 
>consider the ES4 draft that does have classes, and for a still unexplained 
>reason excluded ES1) 
  <snip>

The ES2 standard says, under 'Brief History',

"The ECMA General Assembly of June 1998 
has approved the second edition of ECMA-262 to keep it fully aligned 
with ISO/IEC 16262. Changes from the first edition are editorial in 
nature." 

so ES1 is subsumed by ES2 and is essentially the same document.

If you go to the ECMA 262 web page and follow the link to "historical"
editions you will find it says

"* Please note that for ECMAScript Edition 4 the Ecma standard number
&ldquo;ECMA-262 Edition 4&rdquo; was reserved but not used in the 
Ecma publication process.
Therefore &ldquo;ECMA-262 Edition 4&rdquo; as an Ecma International 
publication does not  exist."

so an ES4 standard does not exist.

Therefore any list of ES standards need not include the ES1 standard
and cannot include an ES4 standard.

I foolishly assumed that you, Thomas, would know all that.


  John

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

#26589

On Mon, 12 Jan 2015 18:01:51 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>   <snip>
>>>> If people can understand that ES2 to ES5.1 contain all the facilities
>>>> needed to implement classes
>>> Your proof of that is pending.
>> 
>> We can only go by the current draft of the ES6 standard, dated 2014
>> Dec 24 at the time of writing. Obviously, it could be totally
>> different when the candidate standard is approved. […]

That isn't what I wrote. And you have the cheek to complain about
people misquoting you !


>The proof that is required of you is that “ES2 to ES5.1” (where you did not 
>consider the ES4 draft that does have classes, and for a still unexplained 
>reason excluded ES1) “contain all the facilities needed to implement 
>classes”.  Because *that* is what you claimed.

Obviously I'm talking about ES6 classes (currently draft and
officially subject to change).


>In order to provide that proof you would need to pick at least one real-
>world flavor of class-based inheritance and then show that *all* of its 
>features can be implemented with a conforming implementation of “ES2 to 
>ES5.1” (excluding the ES4 draft).  You would then have proven that it is 
>possible to *fully* implement all the *selected* flavors of class-based 
>inheritance with the aforementioned ECMAScript implementations.
>
>Can you do that?

My chosen "real-world flavor" is (Draft) ES 6 class declarations.
Anything else would be silly.

You, Thomas, are asserting that my precis of the draft specification
of ES6 class declarations is incorrect. According to your own rules
you need to provide evidence of that assertion. When doing this you
must ignore trivial differences such as making a property read-only,
which can't be done directly in ES3. The same effect can be achieved
by not writing to the property. You might also claim that ES6 will be
better at trapping typing errors. Neither is a fundamental difference.


>Only *after* you have done that it makes sense to discuss whether your 
>second claim, that using the term “class” as you prefer to use it *now* is 
>going to help with using ES6’s classes (as they are currently specified in 
>the working draft), has any basis in reality.

The official ES6 term is 'class-like' for things such as date objects,
but you will no doubt react adversely to the word 'class'.

  
  John

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

#26637

John Harris wrote:

> From the earliest JavaScript onward the language(s) have had all the
> facilities needed to implement classes. If more people recognised that
> fact and understood it then there would be fewer terrible
> implementations of inheritance being published and recommended.

You seem to be promulgating a pun here.  The technical word `class` is 
of course named for the common English word `class`, but, as a technical term, has a more specific meaning.  Generally classes in programming are
specific meta-data implementations of an abstract type, a template used 
to create similar objects.  Of course Javascript has the tools to create
collections of similar objects -- the English word "class" -- but that it
has the the facilities to implement "classes" in this technical sense is
more debatable.


> It might even dissuade people from calling ECMAScript a prototypal
> language, which it clearly isn't. (Evidence : In a prototypal language
> new objects are created by cloning existing prototype objects.
> ECMAScript constructors do not clone.)

You are confusing the specific (concatenative prototyping) with the 
general (prototyping).  Javascript uses delegation-based prototyping
instead.  This is no less a form of prototyping than the concatenative
one.

  -- Scott

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

#26643

On 01/21/2015 07:00 PM, Scott Sauyet wrote:
> John Harris wrote:
> 
>> From the earliest JavaScript onward the language(s) have had all the
>> facilities needed to implement classes. If more people recognised that
>> fact and understood it then there would be fewer terrible
>> implementations of inheritance being published and recommended.
> 
> You seem to be promulgating a pun here.  The technical word `class` is 
> of course named for the common English word `class`, but, as a technical term, has a more specific meaning.  Generally classes in programming are
> specific meta-data implementations of an abstract type, a template used 
> to create similar objects.  Of course Javascript has the tools to create
> collections of similar objects -- the English word "class" -- but that it
> has the the facilities to implement "classes" in this technical sense is
> more debatable.
> 
> 
>> It might even dissuade people from calling ECMAScript a prototypal
>> language, which it clearly isn't. (Evidence : In a prototypal language
>> new objects are created by cloning existing prototype objects.
>> ECMAScript constructors do not clone.)
> 
> You are confusing the specific (concatenative prototyping) with the 
> general (prototyping).  Javascript uses delegation-based prototyping
> instead.  This is no less a form of prototyping than the concatenative
> one.

ACK.

The term 'class' is one of the future reserved words in ECMAScript
Language Specification [1]. And the only 'class' available in ECMAScript
is an invisible internal property called [[Class]] of the String type
domain, common to all objects [2].

David Hermann, who holds a BA, MS and PhD in computer science and serves
on Ecma TC39, stated in his invaluable 'Effective JavaScript' book, item
40: "Don’t let the name mislead you — JavaScript doesn’t secretly have
an internal class system. The value of [[Class]] is just a simple tag:
Array objects (created by the Array constructor or the [] syntax) are
stamped with the [[Class]] value "Array", functions are stamped with the
[[Class]] value "Function", and so on."


[1] <http://ecma-international.org/ecma-262/5.1/#sec-7.6.1.2>
[2] <http://ecma-international.org/ecma-262/5.1/#sec-8.6.2>

-- 
Joao Rodrigues

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

#26646

On Wed, 21 Jan 2015 20:53:27 -0200, Joao Rodrigues
<groups_jr-1@yahoo.com> wrote:


  <snip>
>David Hermann, who holds a BA, MS and PhD in computer science
  <snip>

Snap.

  John

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

#26647

On 22/01/2015 09:43, John Harris wrote:
> On Wed, 21 Jan 2015 20:53:27 -0200, Joao Rodrigues
> <groups_jr-1@yahoo.com> wrote:
> 
> 
>   <snip>
>> David Hermann, who holds a BA, MS and PhD in computer science
>   <snip>
> 
> Snap.

You snipped the most important part of my post: "and serves on Ecma
TC39". Therefore I consider David's book an insider information on the
internals of the ECMAScript Language.


-- 
Joao Rodrigues

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

#26674

On Thu, 22 Jan 2015 10:20:38 -0200, Joao Rodrigues
<groups_jr-1@yahoo.com.br> wrote:

>On 22/01/2015 09:43, John Harris wrote:
>> On Wed, 21 Jan 2015 20:53:27 -0200, Joao Rodrigues
>> <groups_jr-1@yahoo.com> wrote:
>> 
>> 
>>   <snip>
>>> David Hermann, who holds a BA, MS and PhD in computer science
>>   <snip>
>> 
>> Snap.
>
>You snipped the most important part of my post: "and serves on Ecma
>TC39". Therefore I consider David's book an insider information on the
>internals of the ECMAScript Language.

The current draft of the ES6 standard calls them 'class-like', so it
looks as though the committee sees things in much the same way as I
do.

  John

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

#26736

Joao Rodrigues wrote:

> The term 'class' is one of the future reserved words in ECMAScript
> Language Specification [1]. And the only 'class' available in ECMAScript
> is an invisible internal property called [[Class]] of the String type
> domain, common to all objects [2].

s/invisible/abstract, directly inaccessible/

As you quoted below, the “[[Class]]” property is a *Specification mechanism* 
only, used to describe steps and execution paths in Specification 
algorithms.  It does not need to be implemented under that name at all; it 
is sufficient that the implementation behaves as specified in the algorithm 
in order to be conforming.

Property *visibility* is a *different* concept in OOP.  With regard to 
ECMAScript, it is only supported by implementations of the abandoned Edition 
4 working draft, in particular by Microsoft JScript .NET and 
Macromedia/Adobe ActionScript 2.0+:

<https://msdn.microsoft.com/en-us/library/hwyay84b(v=vs.90).aspx>
<http://www.adobe.com/devnet/actionscript/learning/oop-concepts/writing-classes.html>

> David Hermann […]: "[…] The value of [[Class]] is just a simple tag:
> Array objects (created by the Array constructor or the [] syntax) are
> stamped with the [[Class]] value "Array", functions are stamped with the
> [[Class]] value "Function", and so on."

-- 
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]

#26645

On Wed, 21 Jan 2015 13:00:59 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

>John Harris wrote:
>
>> From the earliest JavaScript onward the language(s) have had all the
>> facilities needed to implement classes. If more people recognised that
>> fact and understood it then there would be fewer terrible
>> implementations of inheritance being published and recommended.
>
>You seem to be promulgating a pun here.  The technical word `class` is 
>of course named for the common English word `class`, but, as a technical term, has a more specific meaning.  Generally classes in programming are
>specific meta-data implementations of an abstract type, a template used 
>to create similar objects.  Of course Javascript has the tools to create
>collections of similar objects -- the English word "class" -- but that it
>has the the facilities to implement "classes" in this technical sense is
>more debatable.

The key phrase in what I wrote is *implement* classes. All that the
class keyword in ES6 (draft) does is to cause the compiler to create a
prototype chain and constructor function, just as programmers can do
themselves in ES 2, 3, & 5.1.

I'll say again that if programmers understand this when ES 6 comes out
they'll have a better understanding of what their code is doing. This
will help them find mistakes when the code doesn't do what was
intended.

After understanding it they can wrap the subject up in mysticism and
high-falutin' phrases when they give speeches at meetings and
conferences if they wish.


>> It might even dissuade people from calling ECMAScript a prototypal
>> language, which it clearly isn't. (Evidence : In a prototypal language
>> new objects are created by cloning existing prototype objects.
>> ECMAScript constructors do not clone.)
>
>You are confusing the specific (concatenative prototyping) with the 
>general (prototyping).  Javascript uses delegation-based prototyping
>instead.  This is no less a form of prototyping than the concatenative
>one.

C++ uses data structures that do the same job as prototype chains but
can't be modified by the program. C++ isn't called a prototypal
language.

A C++ object uses the same function code for it's derived methods as
used by objects of the ancestor classes. C++ isn't said to use
delegation-based prototyping.

I don't think prototype chains make the ECMAScript language(s) a
prototypal language (you don't say that, but others do). And calling
it delegation-based prototyping confuses and obscures what's really
going on.

  John

PS Please feel free to disagree without invective.

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

#26648

John Harris wrote:

> On Wed, 21 Jan 2015 13:00:59 -0800 (PST), Scott Sauyet
> <scott.sauyet@gmail.com> wrote:
> 
>> John Harris wrote:
>>
>>> It might even dissuade people from calling ECMAScript a prototypal
>>> language, which it clearly isn't. (Evidence : In a prototypal language
>>> new objects are created by cloning existing prototype objects.
>>> ECMAScript constructors do not clone.)
>>
>> You are confusing the specific (concatenative prototyping) with the 
>> general (prototyping).  Javascript uses delegation-based prototyping
>> instead.  This is no less a form of prototyping than the concatenative
>> one.
> 
> C++ uses data structures that do the same job as prototype chains but
> can't be modified by the program. C++ isn't called a prototypal
> language.
> 
> A C++ object uses the same function code for it's derived methods as
> used by objects of the ancestor classes. C++ isn't said to use
> delegation-based prototyping.
> 
> I don't think prototype chains make the ECMAScript language(s) a
> prototypal language (you don't say that, but others do). And calling
> it delegation-based prototyping confuses and obscures what's really
> going on.

Well, have you consider that it's possible to create objects without
using the `new` operator?  Object.create() most certainly allows for
prototypal programming.

-- 
Christoph M. Becker

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

#26668

On Thu, 22 Jan 2015 13:27:34 +0100, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

  <snip>
>Well, have you consider that it's possible to create objects without
>using the `new` operator?  Object.create() most certainly allows for
>prototypal programming.

Compare
  function Thing(){ }
  Thing.prototype = O;  // O defined elsewhere
  var t0 = new Thing();
with
  var t1 = object.create(O);

I see no difference between the objects referenced by t0 and t1.

  John

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

#26672

John Harris wrote:
> Christoph M. Becker wrote:

>> Well, have you consider that it's possible to create objects without
>> using the `new` operator?  Object.create() most certainly allows for
>> prototypal programming.
> 
> Compare
>   function Thing(){ }
>   Thing.prototype = O;  // O defined elsewhere
>   var t0 = new Thing();
> with
>   var t1 = object.create(O);
> 
> I see no difference between the objects referenced by t0 and t1.

Right, and I'm fairly certain that Christoph Becker was making the 
point that `t1` was clearly made by a prototypal system.  And if
it's not distinguishable from `t0`, then one can say that the
constructor-function syntax also invokes a prototypal system.

Are you suggesting otherwise?

  -- Scott

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

#26677

Scott Sauyet wrote:

> John Harris wrote:
>> Christoph M. Becker wrote:
> 
>>> Well, have you consider that it's possible to create objects without
>>> using the `new` operator?  Object.create() most certainly allows for
>>> prototypal programming.
>>
>> Compare
>>   function Thing(){ }
>>   Thing.prototype = O;  // O defined elsewhere
>>   var t0 = new Thing();
>> with
>>   var t1 = object.create(O);

(That should be `_O_bject.create(O)`, BTW.)

>> I see no difference between the objects referenced by t0 and t1.
> 
> Right, and I'm fairly certain that Christoph Becker was making the 
> point that `t1` was clearly made by a prototypal system.  

Yes, indeed.

> And if
> it's not distinguishable from `t0`, then one can say that the
> constructor-function syntax also invokes a prototypal system.
> 
> Are you suggesting otherwise?

-- 
Christoph M. Becker

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

#26691

On Fri, 23 Jan 2015 08:51:29 -0800 (PST), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

>John Harris wrote:
>> Christoph M. Becker wrote:
>
>>> Well, have you consider that it's possible to create objects without
>>> using the `new` operator?  Object.create() most certainly allows for
>>> prototypal programming.
>> 
>> Compare
>>   function Thing(){ }
>>   Thing.prototype = O;  // O defined elsewhere
>>   var t0 = new Thing();
>> with
>>   var t1 = object.create(O);
>> 
>> I see no difference between the objects referenced by t0 and t1.
>
>Right, and I'm fairly certain that Christoph Becker was making the 
>point that `t1` was clearly made by a prototypal system.  And if
>it's not distinguishable from `t0`, then one can say that the
>constructor-function syntax also invokes a prototypal system.
>
>Are you suggesting otherwise?

Yes. If you replace the name 'prototype chain' with 'inheritance
chain' you get a different view. A view that avoids any overspill from
the ordinary meaning of 'prototype'.

An inheritance chain is a linked list of objects that carry pointers
(references) to own methods and inherited methods. I say that giving
it the name 'prototype chain' was likely to mislead, and did do.

  John

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

#26695

John Harris wrote:
> If you replace the name 'prototype chain' with 'inheritance
> chain' you get a different view. A view that avoids any overspill from
> the ordinary meaning of 'prototype'.
> 
> An inheritance chain is a linked list of objects that carry pointers
> (references) to own methods and inherited methods. I say that giving
> it the name 'prototype chain' was likely to mislead, and did do.

I tend to think of inheritance as a static, compile-time feature.  Because
prototype delegation is a dynamic, run-time feature, I prefer to separate
them entirely.

  -- Scott

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web