Joao Rodrigues
1/7/2015 2:46:00 AM
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