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

#26465 — Can somebody explain this to me

The code at the end works but I have a question.
When I have this code construction with prototype I can call the getFoo in 
this way  var poo = f.getFoo(); // "bar"
 P.prototype.getFoo = function ()
       {
           return this.foo;
       };


I mean if I add this piece of code into the class definition I can call the 
getFoo in this way  var poo = f.getFoo(); // "bar"

this.getFoo = function ()
           {
               return this.foo;
           };

So as a summary can somebody explain what is the advantage to use a 
prototype in this exemple?


Here is the complete code
********************
<script type="text/javascript">

       function P(foo) //Here is the class definition
       {
           this.foo = foo;
           // implicit return av "this" i den fall då P anropas som 
konstruktor

       }

       P.prototype.getFoo = function ()
       {
           return this.foo;
       };

       var f = new P("bar");
       var g = new P("baz");

       var poo = f.getFoo(); // "bar"
       g.getFoo(); // "baz"
   </script>

[toc] | [next] | [standalone]

#26466

Tony Johansson wrote:

> The code at the end works but I have a question.
> When I have this code construction with prototype I can call the getFoo in
> this way  var poo = f.getFoo(); // "bar"
>  P.prototype.getFoo = function ()
>        {

I recommend to put the opening brace of a function expression on the same 
line as the “function” keyword in order to tell function declarations and 
function expressions apart more easily.

>            return this.foo;
>        };
> 
> 
> 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.

> I can call the getFoo in this way  var poo = f.getFoo(); // "bar"
                       ^ method

> this.getFoo = function ()
>            {
>                return this.foo;
>            };
> 
> So as a summary can somebody explain what is the advantage to use a
> prototype in this exemple?

Inherited methods can be reused.  In this example, one advantage is that 
only one Function instance is created, which saves memory as compared to the 
instance method approach.  It also saves runtime because the creation of 
that object only happens once.  (There are also disadvantages.)
 
>        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”.

>        {
>            this.foo = foo;
>            // implicit return av "this" i den fall då P anropas som
> konstruktor

Correct.

>        var f = new P("bar");

Using the “new” keyword on a reference to an object that implements the 
internal [[Construct]] method (which applies to Function instances) calls 
that object as a constructor.

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

#26467

On Tue, 06 Jan 2015 01:40:16 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Tony Johansson wrote:
>
>> The code at the end works but I have a question.
>> When I have this code construction with prototype I can call the getFoo in
>> this way  var poo = f.getFoo(); // "bar"
>>  P.prototype.getFoo = function ()
>>        {
>
>I recommend to put the opening brace of a function expression on the same 
>line as the “function” keyword in order to tell function declarations and 
>function expressions apart more easily.

And I recommend that you don't change, though a smaller indent
wouldn't hurt. Having the curly brackets lined up makes it easier to
see where the code body begins and ends, especially when the body
contains inner function definitions.


>>            return this.foo;
>>        };
>> 
>> 
>> I mean if I add this piece of code into the class definition
>
>There are no classes in this case; 

Not true. See an earlier thread.


>prototype-based inheritance is used.

>> I can call the getFoo in this way  var poo = f.getFoo(); // "bar"
>                       ^ method
>
>> this.getFoo = function ()
>>            {
>>                return this.foo;
>>            };
>> 
>> So as a summary can somebody explain what is the advantage to use a
>> prototype in this exemple?
>
>Inherited methods can be reused.  In this example, one advantage is that 
>only one Function instance is created, which saves memory as compared to the 
>instance method approach.  It also saves runtime because the creation of 
>that object only happens once.  (There are also disadvantages.)
> 
>>        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.


  John

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

#26468

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tony Johansson wrote:
>>> The code at the end works but I have a question.
>>> When I have this code construction with prototype I can call the getFoo
>>> in
>>> this way  var poo = f.getFoo(); // "bar"
>>>  P.prototype.getFoo = function ()
>>>        {
>>
>>I recommend to put the opening brace of a function expression on the same
>>line as the “function” keyword in order to tell function declarations and
>>function expressions apart more easily.
> 
> And I recommend that you don't change, though a smaller indent
> wouldn't hurt. Having the curly brackets lined up makes it easier to
> see where the code body begins and ends, especially when the body
> contains inner function definitions.

However, as you have provably little if any theoretical knowledge of and 
practical experience with the programming languages in question, your 
recommendations should be weighed against that.

There is an important difference between function declarations and function 
expressions that is _not_ syntactical, and it is wise to write source code 
so that such differences are easier to see.
 
>>>            return this.foo;
>>>        };
>>> 
>>> 
>>> I mean if I add this piece of code into the class definition
>>
>>There are no classes in this case;
> 
> Not true. See an earlier thread.

In the earlier thread you already failed to provide convincing, let alone 
non-fallacious arguments that the terminology you prefer, in the way you 
prefer it, is useful in a technical discussion on the subjects that are on-
topic here.
 
>>prototype-based inheritance is used.
> 
>>> I can call the getFoo in this way  var poo = f.getFoo(); // "bar"
>>                       ^ method
>>
>>> this.getFoo = function ()
>>>            {
>>>                return this.foo;
>>>            };
>>> 
>>> So as a summary can somebody explain what is the advantage to use a
>>> prototype in this exemple?
>>
>>Inherited methods can be reused.  In this example, one advantage is that
>>only one Function instance is created, which saves memory as compared to
>>the instance method approach.  It also saves runtime because the creation 
>>of that object only happens once.  (There are also disadvantages.)
>> 
>>>        function P(foo) //Here is the class definition
>   <snip>
> 
> No; here is the class's constructor function.

Utter nonsense.

> The class's definition has to be deduced from the code,

There is no class as there are no classes in the respective original 
language (what is created from that by compilers for virtual machines for 
optimization, indeed, is irrelevant in that regard).

Therefore there is no “class definition” to “deduce” other than that which 
can only be ascribed to either too vivid imagination or utter wannabe-ness.  
The constructor function’s declaration, on the other hand, is plain to see, 
it can be looked up in authoritative reference material, and it is what this 
code is being parsed as by *all* relevant script engines.

> which is presumably why some people say ECMAScript, up to v5 at least, has
> no classes.

ECMAScript Editions 1 to 3, and 5.x, simply do not; neither have their 
implementations.  (The abandoned Edition 4 working draft is irrelevant with 
regard to client-side code in Web browsers, but it must be excluded from 
that list.)

However, ECMAScript Edition 6 and its implementations are going to, and they 
are going to have prototype-based inheritance as well.  Therefore it is not 
useful to call something a class that is not called a class in any 
authoritative reference material.  Please stop confusing people who seek 
clarity here.

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

#26476

On 01/06/2015 02:26 PM, Thomas 'PointedEars' Lahn wrote:
> John Harris wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Tony Johansson wrote:

<snip>

>>>>            return this.foo;
>>>>        };
>>>>
>>>>
>>>> I mean if I add this piece of code into the class definition
>>>
>>> There are no classes in this case;
>>
>> Not true. See an earlier thread.
> 
> In the earlier thread you already failed to provide convincing, let alone 
> non-fallacious arguments that the terminology you prefer, in the way you 
> prefer it, is useful in a technical discussion on the subjects that are on-
> topic here.
>  
>>> prototype-based inheritance is used.
>>
>>>> I can call the getFoo in this way  var poo = f.getFoo(); // "bar"
>>>                       ^ method
>>>
>>>> this.getFoo = function ()
>>>>            {
>>>>                return this.foo;
>>>>            };
>>>>
>>>> So as a summary can somebody explain what is the advantage to use a
>>>> prototype in this exemple?
>>>
>>> Inherited methods can be reused.  In this example, one advantage is that
>>> only one Function instance is created, which saves memory as compared to
>>> the instance method approach.  It also saves runtime because the creation 
>>> of that object only happens once.  (There are also disadvantages.)
>>>
>>>>        function P(foo) //Here is the class definition
>>   <snip>
>>
>> No; here is the class's constructor function.
> 
> Utter nonsense.
> 
>> The class's definition has to be deduced from the code,
> 
> There is no class as there are no classes in the respective original 
> language (what is created from that by compilers for virtual machines for 
> optimization, indeed, is irrelevant in that regard).
> 
> Therefore there is no “class definition” to “deduce” other than that which 
> can only be ascribed to either too vivid imagination or utter wannabe-ness.  
> The constructor function’s declaration, on the other hand, is plain to see, 
> it can be looked up in authoritative reference material, and it is what this 
> code is being parsed as by *all* relevant script engines.
> 
>> which is presumably why some people say ECMAScript, up to v5 at least, has
>> no classes.
> 
> ECMAScript Editions 1 to 3, and 5.x, simply do not; neither have their 
> implementations.  (The abandoned Edition 4 working draft is irrelevant with 
> regard to client-side code in Web browsers, but it must be excluded from 
> that list.)

In _Effective JavaScript_, David Herman, a member of the Ecma TC39, the
committee responsible for the standardization of JavaScript, wrote:

"4. Objects and Prototypes

Objects are JavaScript’s fundamental data structure. Intuitively, an
object represents a table relating strings to values. But when you dig
deeper, there is a fair amount of machinery that goes into objects.
Like many object-oriented languages, JavaScript provides support for
implementation inheritance: the reuse of code or data through a dynamic
delegation mechanism. _But unlike many conventional languages,
JavaScript’s inheritance mechanism is based on prototypes rather than
classes. For many programmers, JavaScript is the first object-oriented
language they encounter without classes._

In many languages, every object is an instance of an associated class,
which provides code shared between all its instances. JavaScript, by
contrast, has no built-in notion of classes. Instead, objects inherit
from other objects. Every object is associated with some other object,
known as its prototype. Working with prototypes can be different from
classes, although many concepts from traditional object-oriented
languages still carry over."

> 
> However, ECMAScript Edition 6 and its implementations are going to, and they 
> are going to have prototype-based inheritance as well.  Therefore it is not 
> useful to call something a class that is not called a class in any 
> authoritative reference material.  Please stop confusing people who seek 
> clarity here.
> 

ACK.

-- 
Joao Rodrigues

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

#26478

Joao Rodrigues wrote:

> In _Effective JavaScript_, David Herman, a member of the Ecma TC39, the
> committee responsible for the standardization of JavaScript, wrote: […]

The Ecma Technical Committee (TC) 39 is _not_ “responsible for the 
standardization of JavaScript”; it never has been (the first Edition of 
ECMAScript already reconciled differences between Netscape JavaScript and 
Microsoft *JScript*).  They are responsible for publishing working drafts of 
Editions of the ECMAScript Language Specification and related specifications 
for the Ecma (International) General Assembly to vote on, so that they can 
become an Ecma Standard.

The programming languages that carry the “JavaScript” name, AFAIK most of 
them without due licensing, are not the only (conforming) implementations of 
the Editions of ECMAScript.

ACK to the rest.

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

#26486

On 07/01/2015 01:35, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
> 
>> In _Effective JavaScript_, David Herman, a member of the Ecma TC39, the
>> committee responsible for the standardization of JavaScript, wrote: […]
> 
> The Ecma Technical Committee (TC) 39 is _not_ “responsible for the 
> standardization of JavaScript”;

According to the Ecma TC39's site [1], standardization of ECMAScript is
in their scope of work:

"Scope:
Standardization of the general purpose, cross platform, vendor-neutral
programming language ECMAScript. This includes the language syntax,
semantics, and libraries and complementary technologies that support the
language.

Programme of work:
1. To maintain and update the standard for the ECMAScript programming
language.
2. To identify, develop and maintain standards for libraries that extend
the capabilities of ECMAScript.
3. To develop test suites that may be used to verify correct
implementation of these standards.
4. To contribute selected standards to ISO/IEC JTC 1.
5. To evaluate and consider proposals for complementary or additional
technologies.

In another document [2], they state that:

"ECMAScript™, _which is more commonly known by the name JavaScript™_, is
an essential component of every web browser and the ECMAScript™ standard
is one of the core standards that enable the existence of interoperable
web applications on the World Wide Web.

The ECMAScript™ specification has been developed by Ecma TC39 whose
membership includes all major browser vendors. The candidate milestone
designates that the authoring process was completed, followed by a
testing and validation phase of the project where TC39 members create
and test implementations of the candidate specification to verify its
correctness and the feasibility of creating interoperable
implementations. The test implementations will also be used for web
compatibility testing to ensure that the revised specification remains
compatible with existing web applications. TC39 has committed to
participating in this testing process."


[1] <http://www.ecma-international.org/memento/TC39.htm>
[2] <http://www.ecma-international.org/memento/TC39-M.htm>

> it never has been (the first Edition of 
> ECMAScript already reconciled differences between Netscape JavaScript and 
> Microsoft *JScript*).

It seems obvious to me as ECMAScript dates from 1997, whereas Netscape
JavaScript and Microsoft JScript date from 1996.

> They are responsible for publishing working drafts of 
> Editions of the ECMAScript Language Specification and related specifications 
> for the Ecma (International) General Assembly to vote on, so that they can 
> become an Ecma Standard.

This is not entirely true. See the references above.

-- 
Joao Rodrigues

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

#26487

Joao Rodrigues wrote:

> On 07/01/2015 01:35, Thomas 'PointedEars' Lahn wrote:
>> Joao Rodrigues wrote:
>>> In _Effective JavaScript_, David Herman, a member of the Ecma TC39, the
>>> committee responsible for the standardization of JavaScript, wrote: […]
>> The Ecma Technical Committee (TC) 39 is _not_ “responsible for the
>> standardization of JavaScript”;
> 
> According to the Ecma TC39's site [1], standardization of ECMAScript is
> in their scope of work:
> 
> "Scope:
> Standardization of the general purpose, cross platform, vendor-neutral
> programming language ECMAScript. […]

Yes, standardization of _ECMAScript_, _not_ JavaScript.

> In another document [2], they state that:
> 
> "ECMAScript™, _which is more commonly known by the name JavaScript™_ […]

An explanation for laymen, which as all such explanations is imprecise at 
best.  As you can also read in the section “Foreword and Rationale” of the 
ECMAScript Support Matrix (see my sig), ECMAScript and JavaScript are 
different things.  (Netscape, now Mozilla) JavaScript™ is an implementation 
of ECMAScript, one of many.

Conforming implementations of ECMAScript are permitted to extend both the 
syntactical and the functional feature set of ECMAScript (see the 
“Conformance” sections of the Editions).  AISB, the names of some 
implementations (the question aside whether they are actually conforming; 
the Matrix can tell), now contain “JavaScript” without proper authorization 
from the trademark owner (Oracle Corp., formerly Sun Microsystems Inc.), nor 
does their feature set justify use of that trademark; at least one 
(Microsoft JScript 9.0+) does it purely for marketing.

>> it never has been (the first Edition of
>> ECMAScript already reconciled differences between Netscape JavaScript and
>> Microsoft *JScript*).
> 
> It seems obvious to me as ECMAScript dates from 1997, whereas Netscape
> JavaScript and Microsoft JScript date from 1996.

Therefore, statements like yours, that exclude JScript, among other 
implementations, from the definition of ECMAScript, are wrong.

Likewise, to date all statements that say something would be an 
“implementation of JavaScript” have been wrong.  For if we allow for the 
possibility that there could be an implementation of an implementation, such 
a software must at least support the entire feature set of the software it 
is based on, which has not been the case to date.

>> They are responsible for publishing working drafts of Editions of the 
>> ECMAScript Language Specification and related specifications for the
>> Ecma (International) General Assembly to vote on, so that they can become 
>> an Ecma Standard.
> 
> This is not entirely true. See the references above.

I can see nothing in that which you cited that contradicts my description.

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

#26488

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 07 jan 2015 in 
comp.lang.javascript:

> Yes, standardization of _ECMAScript_, _not_ JavaScript.

Why would you speak about standardisation 
of something you claim not to exist?

Do you want to standardize that it does not exist?

Or do you now suddenly claim Javascript exists,
but is not the same as ECMAScript.

If so, why?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26489

Evertjan. wrote:

> Thomas 'PointedEars' Lahn […] wrote:
>> Yes, standardization of _ECMAScript_, _not_ JavaScript.
> 
> Why would you speak about standardisation
> of something you claim not to exist?

Pardon?

> Do you want to standardize that it does not exist?

You are not making sense.

> Or do you now suddenly claim Javascript exists,
> but is not the same as ECMAScript.

I have not claimed that Javascript exists, and I would not claim that.

ISTM that you are either not paying attention or are still challenged with 
understanding English.

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

#26490

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 08 jan 2015 in 
comp.lang.javascript:

> ISTM that you are either not paying attention or are still challenged with 
> understanding English.

It might be that I am not understanding YOUR English, 
your English certainly does not challenge me,
even if YOU want to pay ME for my attention.

Your ad hominem remarks only reflect on yourself, btw.

Oh please, have some fun in life,
and in Javascript. 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26497

Evertjan. wrote:

> Thomas 'PointedEars' Lahn wrote:
>> ISTM that you are either not paying attention or are still challenged
>> with understanding English.
> 
> It might be that I am not understanding YOUR English,
> your English certainly does not challenge me,

Yes, it does.

> even if YOU want to pay ME for my attention.
> 
> Your ad hominem remarks only reflect on yourself, btw.

There is no ad hominem remark.  You claimed that I claimed
something which I did not. I strongly suggest you learn to
read, ask about what you do not understand, or be silent.

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

#26499

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 08 jan 2015 in 
comp.lang.javascript:

>> your English certainly does not challenge me,
> 
> Yes, it does.

How would you know.

See, you don't understand a simple sentense.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26501

Evertjan. wrote:

> Thomas 'PointedEars' Lahn [wrote]:
>>> your English certainly does not challenge me,
>> 
>> Yes, it does.
> 
> How would you know.

Is that a question.  (You see, *evidentially* you do not know English well 
enough.)

There is absolutely nothing in what I wrote, which you referred to, that 
even remotely suggests I would claim something does not exist, different 
from what you insinuated.  When you are ready to accept that we might make 
some progress.  Until then, EOD for me.

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

#26482

On Tue, 06 Jan 2015 17:26:24 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Tony Johansson wrote:
>>>> The code at the end works but I have a question.
>>>> When I have this code construction with prototype I can call the getFoo
>>>> in
>>>> this way  var poo = f.getFoo(); // "bar"
>>>>  P.prototype.getFoo = function ()
>>>>        {
>>>
>>>I recommend to put the opening brace of a function expression on the same
>>>line as the ?function? keyword in order to tell function declarations and
>>>function expressions apart more easily.
>> 
>> And I recommend that you don't change, though a smaller indent
>> wouldn't hurt. Having the curly brackets lined up makes it easier to
>> see where the code body begins and ends, especially when the body
>> contains inner function definitions.
>
>However, as you have provably little if any theoretical knowledge of and 
>practical experience with the programming languages in question, your 
>recommendations should be weighed against that.
>
>There is an important difference between function declarations and function 
>expressions that is _not_ syntactical, and it is wise to write source code 
>so that such differences are easier to see.
> 
>>>>            return this.foo;
>>>>        };
>>>> 
>>>> 
>>>> I mean if I add this piece of code into the class definition
>>>
>>>There are no classes in this case;
>> 
>> Not true. See an earlier thread.
>
>In the earlier thread you already failed to provide convincing, let alone 
>non-fallacious arguments that the terminology you prefer, in the way you 
>prefer it, is useful in a technical discussion on the subjects that are on-
>topic here.

Hear ye, hear ye, all followers of comp.lang.javascript :-

  It is *utterly forbidden* to disagree with Thomas Lahn.
  There will be *no* discussion of other viewpoints whatsoever.


>>>prototype-based inheritance is used.
>> 
>>>> I can call the getFoo in this way  var poo = f.getFoo(); // "bar"
>>>                       ^ method
>>>
>>>> this.getFoo = function ()
>>>>            {
>>>>                return this.foo;
>>>>            };
>>>> 
>>>> So as a summary can somebody explain what is the advantage to use a
>>>> prototype in this exemple?
>>>
>>>Inherited methods can be reused.  In this example, one advantage is that
>>>only one Function instance is created, which saves memory as compared to
>>>the instance method approach.  It also saves runtime because the creation 
>>>of that object only happens once.  (There are also disadvantages.)
>>> 
>>>>        function P(foo) //Here is the class definition
>>   <snip>
>> 
>> No; here is the class's constructor function.
>
>Utter nonsense.

It *is* a constructor function.


>> The class's definition has to be deduced from the code,
>
>There is no class as there are no classes in the respective original 
>language (what is created from that by compilers for virtual machines for 
>optimization, indeed, is irrelevant in that regard).
>
>Therefore there is no “class definition” to “deduce” other than that which 
>can only be ascribed to either too vivid imagination or utter wannabe-ness.  
>The constructor function’s declaration, on the other hand, is plain to see, 
>it can be looked up in authoritative reference material, and it is what this 
>code is being parsed as by *all* relevant script engines.

From the code one can deduce what kind of objects are going to be
constructed. It would be advantageous if that were written down in the
program's documentation before coding, especially in a large-scale
project.

You could argue that the documentation should be called a kind
definition if you wish.


>> which is presumably why some people say ECMAScript, up to v5 at least, has
>> no classes.
>
>ECMAScript Editions 1 to 3, and 5.x, simply do not; neither have their 
>implementations.  (The abandoned Edition 4 working draft is irrelevant with 
>regard to client-side code in Web browsers, but it must be excluded from 
>that list.)
>
>However, ECMAScript Edition 6 and its implementations are going to, and they 
>are going to have prototype-based inheritance as well.
  <snip>  

It is obvious that you, Thomas, are not familiar with C++ V-tables.
They do exactly the same job as an ECMAScript prototype chain but are
far more efficient and cannot be altered by the user code, or even
accessed. 

V-tables are the obvious data structures to do the job but the
Standard allows compilers to use any means they wish. A compiler could
even use ECMAScript prototype chains, but wouldn't as it would be too
slow and unnecessarily complicated.


  John

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

#26484

John Harris wrote:

> It is obvious that you, Thomas, are not familiar with C++ V-tables.
> They do exactly the same job as an ECMAScript prototype chain but are
> far more efficient and cannot be altered by the user code, or even
> accessed. 
> 
> V-tables are the obvious data structures to do the job but the
> Standard allows compilers to use any means they wish. A compiler could
> even use ECMAScript prototype chains, but wouldn't as it would be too
> slow and unnecessarily complicated.

I consider it rather unlikely that an ECMAScript implementation uses
vtables for property lookup; more likely they might use hash tables
caches to avoid repeated traversal of the prototype chain.

However, claiming or even assuming is somewhat inappropriate for a
technical newsgroup -- a proof would be preferable.

-- 
Christoph M. Becker

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

#26494

On Wed, 07 Jan 2015 17:01:05 +0100, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> It is obvious that you, Thomas, are not familiar with C++ V-tables.
>> They do exactly the same job as an ECMAScript prototype chain but are
>> far more efficient and cannot be altered by the user code, or even
>> accessed. 
>> 
>> V-tables are the obvious data structures to do the job but the
>> Standard allows compilers to use any means they wish. A compiler could
>> even use ECMAScript prototype chains, but wouldn't as it would be too
>> slow and unnecessarily complicated.
>
>I consider it rather unlikely that an ECMAScript implementation uses
>vtables for property lookup; more likely they might use hash tables
>caches to avoid repeated traversal of the prototype chain.
>
>However, claiming or even assuming is somewhat inappropriate for a
>technical newsgroup -- a proof would be preferable.

I'm afraid you've misread what I wrote. I said that a C++ compiler is
permitted to use prototype chains if it wishes to (but it never will
wish to).

I did not say anything about ECMAScript implementations. Indeed,
V-tables are fixed arrays that rely on variables having fixed names
and on no change by the program so are very unsuitable.

  John

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

#26495

John Harris wrote:

> On Wed, 07 Jan 2015 17:01:05 +0100, "Christoph M. Becker"
> <cmbecker69@arcor.de> wrote:
> 
>> John Harris wrote:
>>
>>> It is obvious that you, Thomas, are not familiar with C++ V-tables.
>>> They do exactly the same job as an ECMAScript prototype chain but are
>>> far more efficient and cannot be altered by the user code, or even
>>> accessed. 
>>>
>>> V-tables are the obvious data structures to do the job but the
>>> Standard allows compilers to use any means they wish. A compiler could
>>> even use ECMAScript prototype chains, but wouldn't as it would be too
>>> slow and unnecessarily complicated.
>>
>> I consider it rather unlikely that an ECMAScript implementation uses
>> vtables for property lookup; more likely they might use hash tables
>> caches to avoid repeated traversal of the prototype chain.
>>
>> However, claiming or even assuming is somewhat inappropriate for a
>> technical newsgroup -- a proof would be preferable.
> 
> I'm afraid you've misread what I wrote. I said that a C++ compiler is
> permitted to use prototype chains if it wishes to (but it never will
> wish to).

Indeed, I've misread your post.  Thanks for the clarification.

> I did not say anything about ECMAScript implementations. Indeed,
> V-tables are fixed arrays that rely on variables having fixed names
> and on no change by the program so are very unsuitable.

ACK

-- 
Christoph M. Becker

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

#26498

John Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> There are no classes in this case;
>>> Not true. See an earlier thread.
>> In the earlier thread you already failed to provide convincing, let alone
>> non-fallacious arguments that the terminology you prefer, in the way you
>> prefer it, is useful in a technical discussion on the subjects that are
>> on-topic here.
> 
> Hear ye, hear ye, all followers of comp.lang.javascript :-

There are no followers.  This is Usenet, not Twitter: one *subscribes* to a 
newsgroup. 

>   It is *utterly forbidden* to disagree with Thomas Lahn.
>   There will be *no* discussion of other viewpoints whatsoever.

You use every opportunity to misconstrue, yes?

>>>>>        function P(foo) //Here is the class definition
>>>   <snip>
>>> No; here is the class's constructor function.
>> Utter nonsense.
> 
> It *is* a constructor function.

But _not_ a class’s.

> From the code one can deduce what kind of objects are going to be
> constructed.

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

>>> which is presumably why some people say ECMAScript, up to v5 at least,
>>> has no classes.
>> ECMAScript Editions 1 to 3, and 5.x, simply do not; neither have their
>> implementations.  […]
>> However, ECMAScript Edition 6 and its implementations are going to, and
>> they are going to have prototype-based inheritance as well.
>   <snip>
> 
> It is obvious that you, Thomas, are not familiar with C++ V-tables.
> […]

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

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

#26521

On Thu, 08 Jan 2015 16:43:06 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> 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. Why didn't you say it's just one
word you didn't like?


>> From the code one can deduce what kind of objects are going to be
>> constructed.
>
>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. (Same
property names, same prototype chain). 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.


>> 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. Wow!


  <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". 

A class is a class of objects, not their constructor function(s), nor
their definition (explicit or implicit).


>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. If more people recognised that
fact and understood it then there would be fewer terrible
implementations of inheritance being published and recommended.

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.)


  John

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web