«

There are numerous examples about trying to implement classical inheritance
in javascript. Most authors seem to take for granted that classical
inheritance or simulating it is necessary in any language, incl javascript.

I am ashamed to confess that in spite of about 15 years of using object
oriented languages in my hobbies I am not really convinced about the
usefulness of inheriting. May be that if somebody makes a set of programs
for others to inherit from the idea might be practical. Is it so that
inheritance is needed and useful in big projects, with tens or hundreds of
people coding? But designing class inheritance is waste of energy when
writing some internet pages alone or together with some friends?

The educational examples are about animals, cats and dogs, or persons
becoming employees and managers, or shapes on the screen becoming
rectangles, circles, or vehicles becoming cars and sports cars. But
something bothers me all the time with these examples: why not make those
objects directly without wrestling with inheritance code like

function extend(B, A) {

Intermediate = function (){};
Intermediate.prototype = A.prototype;
B.prototype = new Intermediate();
B.prototype.constructor = B;
B.parentConstructor = A;
}

I would like to see a simple and useful example about classical inheritance
in any language. Convince myself that inheritance there saves from writing
repeated code or helps in maintaining or understanding the situation. After
that I would try to see, how that example could be written in prototypal
language javascript, with simulated classical inheritance or using the
natural features of prototypal language.

When it is possible to add, delete, replace methods and other properties in
the objects using constructor functions simply to do that, why wrestle with
mysterious and astounding features in 'inheritance'? Is the reason simply
that programmers have learnt that inheritance in C++, Java etc must be good
for their health (although they might not be se sure about that: eat more
sallad, I'll eat...).

Peter Michaux has presented an example about subject-observer patterns and
showed some variants to solve that in 'javascript-way' instead of classical
(?) .

http://peter.michaux.ca/articles/tra...ipt-prototypes

There are some astounding sentences/references there like 'Java classes are
a mistake ' (or something like that).

I have to play and learn about this example. In the meantime, can you give
links to examples which have convinced you about the usefulness of classical
inheritance?

On Sep 17, 7:05*am, "optimistx" <optimi...@hotmail.com> wrote:
> [snip]

Without getting into anything specific at this point, I found the
following to be an interesting take on prototypes vs classes:
http://www.helsinki.fi/~jppesone/papers/kandi.html

On Sep 17, 3:05*pm, "optimistx" <optimi...@hotmail.com> wrote:

Hi optimistx.

> function extend(B, A) {
>
> Intermediate = function (){};
> Intermediate.prototype = A.prototype;
> B.prototype = new Intermediate();
> B.prototype.constructor = B;
> B.parentConstructor = A;
>
> }

I know, this is only for example, but:

extend is reserved word from JavaScript. See:
7.5.3 Future Reserved Words in ECMA 3
In someone of the future version, that code will be produce error.

Intermediate in this case, will be defined in scope of `Global
Object`.

B.parentConstructor = A;
I'm confused from that line. What is advantage of this approach?
B is instance from Function object. B have implicit reference to
Function.prototype, Function.prototype have implicit reference to
Object.prototype.
So B.parentConstructor is: function Object(){}.

At the moment i don't see where to use parentConstructor. And what is
advantage of this? Maybe more readeable code? I don't thing so.

Sorry if my post gone to off topic.

On Sep 17, 7:05*am, "optimistx" <optimi...@hotmail.com> wrote:
> There are numerous examples about trying to implement classical inheritance
> in javascript. Most authors seem to take for granted that classical
> inheritance or simulating it is necessary in any language, incl javascript.

classical inheritance, no. Inheritance in general? Maybe.


> I am ashamed to confess that in spite of about 15 years of using object
> oriented languages in my hobbies I am not really convinced about the
> usefulness of inheriting.

I've heard it said by an academician that if you squint hard enough,
inheritance
violates encapsulation. I'm not sure what I think of that though, but
at least
you're not alone in your thoughts.


> May be that if somebody makes a set of programs
> for others to inherit from the idea might be practical. *Is it so that
> inheritance is needed and useful in big projects, with tens or hundreds of
> people coding? But designing class inheritance is waste of energy when
> writing some internet pages alone or together with some friends?

Proper use of prototypical inheritance can and will save you coding
time and
significant memory (code re-use, and no member copying).

> The educational examples are about animals, cats and dogs, or persons
> becoming employees and managers, or shapes on the screen becoming
> rectangles, circles, or vehicles becoming cars and sports cars. But
> something bothers me all the time with these examples: why not make those
> objects directly without wrestling with *inheritance code ...

Many examples and tutorials are convulated due to misguided
understanding
of the problem IMO. Understanding the relationships between the
elements of
your system are fundamental to building code that isn't a self-hosted
hack
into something "good-enough"

> I would like to see a simple and useful example about classical inheritance
> in any language. Convince myself that inheritance there saves from writing
> repeated code or helps in maintaining or understanding the situation. After
> that I would try to see, how that example could be written in prototypal
> language javascript, with simulated classical inheritance or using the
> natural features of prototypal language.

You don't need side by side examples of different languages to
understand
code abstraction. Why would you ever want to copy and paste identical
code definitions
over and over for multiple objects? Verbose code does not
automatically mean readable code.


> When it is possible to add, delete, replace methods and other properties in
> the objects using constructor functions simply to do that, why wrestle with
> mysterious and astounding features in 'inheritance'?

I don't think you properly understand what a constructor does.

On Sep 17, 1:15*pm, -TNO- <t...@thenewobjective.com> wrote:
> On Sep 17, 7:05*am, "optimistx" <optimi...@hotmail.com> wrote:
>
> > There are numerous examples about trying to implement classical inheritance
> > in javascript. *Most authors seem to take for granted that classical
> > inheritance or simulating it is necessary in any language, incl javascript.
>
> classical inheritance, no. Inheritance in general? Maybe.
>
> > I am ashamed to confess that in spite of about 15 years of using object
> > oriented languages in my hobbies I am not really convinced about the
> > usefulness of inheriting.
>
> I've heard it said by an academician that if you squint hard enough,
> inheritance
> violates encapsulation. I'm not sure what I think of that though, but
> at least
> you're not alone in your thoughts.
>
> > May be that if somebody makes a set of programs
> > for others to inherit from the idea might be practical. *Is it so that
> > inheritance is needed and useful in big projects, with tens or hundredsof
> > people coding? But designing class inheritance is waste of energy when
> > writing some internet pages alone or together with some friends?
>
> Proper use of prototypical inheritance can and will save you coding
> time and
> significant memory (code re-use, and no member copying).
>
> > The educational examples are about animals, cats and dogs, or persons
> > becoming employees and managers, or shapes on the screen becoming
> > rectangles, circles, or vehicles becoming cars and sports cars. But
> > something bothers me all the time with these examples: why not make those
> > objects directly without wrestling with *inheritance code ...
>
> Many examples and tutorials are convulated due to misguided
> understanding
> of the problem IMO. Understanding the relationships between the
> elements of
> your system are fundamental to building code that isn't a self-hosted
> hack
> into something "good-enough"
>
> > I would like to see a simple and useful example about classical inheritance
> > in any language. Convince myself that inheritance there saves from writing
> > repeated code or helps in maintaining or understanding the situation. After
> > that I would try to see, how that example could be written in prototypal
> > language javascript, with simulated classical inheritance or using the
> > natural features of prototypal language.
>
> You don't need side by side examples of different languages to
> understand
> code abstraction. Why would you ever want to copy and paste identical
> code definitions
> over and over for multiple objects? Verbose code does not
> automatically mean readable code.
>
> > When it is possible to add, delete, replace methods and other properties in
> > the objects using constructor functions simply to do that, why wrestle with
> > mysterious and astounding features in 'inheritance'?
>
> I don't think you properly understand what a constructor does.

Apologies for bad formatting.

On Thu, 17 Sep 2009 at 15:05:14, in comp.lang.javascript, optimistx
wrote:

<snip>
>I would like to see a simple and useful example about classical
>inheritance in any language. Convince myself that inheritance there
>saves from writing repeated code or helps in maintaining or
>understanding the situation. After that I would try to see, how that
>example could be written in prototypal language javascript, with
>simulated classical inheritance or using the natural features of
>prototypal language.
<snip>

Look no further than the javascript DOM 1 spec if you want a realistic
example :
<http://www.w3.org/TR/REC-DOM-Level-1/>
see the ECMAScript appendix.

There you'll see that HTMLElement objects have all the methods and data
properties of Element objects, which in turn have all the methods and
data properties of Node objects.

John
--
John Harris

abozhilov wrote:
> "optimistx" wrote:
>> function extend(B, A) {
>>
>> Intermediate = function (){};
>> Intermediate.prototype = A.prototype;
>> B.prototype = new Intermediate();
>> B.prototype.constructor = B;
>> B.parentConstructor = A;
>>
>> }
>
> I know, this is only for example, but:
>
> extend is reserved word from JavaScript. See:
> 7.5.3 Future Reserved Words in ECMA 3

The correct caption of the section in all Editions is

| 7.5.3 Future Reserved Words

(Of course, ECMA/Ecma International would not have written obvious nonsense
like "ECMA 3" as the Editions of the ECMAScript Language Specification are
registered under ECMA-262.)

> In someone of the future version, that code will be produce error.

If you would have read more carefully, you would have noticed that the
future reserved word is spelled `extends' (like in Java, from which it is
most certainly taken).

JFYI: I am using a similar approach, but I am augmenting the object referred
to by Function.prototype with an extend() method instead. This has the
advantage of not "spoiling the global namespace", being callable as method
of Function instances, and as it returns a Function instance, can be used in
an assignment expression. It leads to compact, but (IMHO) still readable
code like

/**
* @param s
* @extends jsx.Error
*/
jsx.object.ObjectError = (
function(s) {
arguments.callee._super.call(this, s);
}
).extend(jsx.Error, {
name: "jsx.object.ObjectError"
});

> Intermediate in this case, will be defined in scope of `Global
> Object`.

No. Learn to distinguish between property, execution context and scope. An
object does not have (a) scope (chain); that is only associated with an
execution context. You probably mean instead that the `Intermediate'
identifier will (probably, since we do not know where this code is going to
be used) be implicitly defined in the global execution context, as a
property of the Global Object; know that is not a Bad Thing per se.

> B.parentConstructor = A;
> I'm confused from that line. What is advantage of this approach?

It is syntactic sugar so that B instances know that they inherit from
A.prototype; this is particularly useful if a constructor calls the "parent"
constructor to set properties. In class-based inheritance this is (AFAIK)
used for initialization only; in emulated class-based inheritance in a
dynamic prototype-based language this can also be used to *create*
properties for a certain "class" of objects when they are constructed.

> B is instance from Function object.

In a sense, yes.

> B have implicit reference to Function.prototype, Function.prototype
> have implicit reference to Object.prototype.

But there is no explicit reference to the "parent" constructor.

> So B.parentConstructor is: function Object(){}.

Nonsense.

> At the moment i don't see where to use parentConstructor. And what is
> advantage of this? Maybe more readeable code? I don't thing so.

Think again.

> Sorry if my post gone to off topic.

Your posting was not off-topic, but it was obviously not very good either.
Please make it better next time.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

-TNO- wrote:
> On Sep 17, 1:15 pm, -TNO- <t...@thenewobjective.com> wrote:
>> [full-quote]
>
> Apologies for bad formatting.

I don't see an apology for pointless full-quoting here

If you think that your article is hardly readable (which is not far from the
truth in this case), you should re-post it in what you think is a more
proper fashion, and then remove the bad one. News servers will not notice,
because Google Groups does not send Control messages (unfortunately), but at
least the group's archive would be improved.


HTH

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On Sep 17, 9:31*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> If you would have read more carefully, you would have noticed that the
> future reserved word is spelled `extends' (like in Java, from which it is
> most certainly taken).

Oh my god... My eyes mislead that.. Sorry.

> No. *Learn to distinguish between property, execution context and scope.. *An
> object does not have (a) scope (chain); that is only associated with an
> execution context. *

Yes, here you are right. My terminology is wrong at the moment. This
will be change.

> > B have implicit reference to Function.prototype, Function.prototype
> > have implicit reference to Object.prototype.
>
> But there is no explicit reference to the "parent" constructor.

What are you mean about "parent"? And what is explicit reference to
"parent". In:

A

B -> inherit from A

C -> inherit from B

Who is explicit parent of C? Maybe B?
And what is advantage of this technique, when you have explicit
reference to "parent"?

> > So B.parentConstructor is: function Object(){}.
>
> Nonsense.

Allright. Who is the parent constructor of B in that case? Please
explain.

> > Sorry if my post gone to off topic.
>
> Your posting was not off-topic, but it was obviously not very good either..
> Please make it better next time.

I will be try id.
Thanks for response.

abozhilov wrote:
> Thomas 'PointedEars' Lahn wrote:
>>> B have implicit reference to Function.prototype, Function.prototype
>>> have implicit reference to Object.prototype.
>> But there is no explicit reference to the "parent" constructor.
>
> What are you mean about "parent"? And what is explicit reference to
> "parent".

.... constructor: In class-based inheritance, this would be constructor of
the parent/super class; in emulated class-based inheritance in a
prototype-based language, this is the constructor that provides the
prototype object from which the prototype object of the instance about to be
constructed inherits through the prototype chain.

> In:
>
> A
>
> B -> inherit from A

You mean: B.prototype inherits from A.prototype (while disregarding, for
brevity, that these are merely object references).

> C -> inherit from B

You mean: C.prototype inherits from B.prototype.

> Who is explicit parent of C? Maybe B?

Yes. But I was not talking about an "explicit parent", but
about an "explicit reference to the 'parent' constructor".

> And what is advantage of this technique, when you have explicit
> reference to "parent"?

Told you. In addition, what should go without saying is that the explicit
reference avoids the implicit reference; that is a Good Thing because then
the prototype object from which the prototype of the constructed instance
inherits does not need to provide a `constructor' property. Or, in other
words, referencing the "parent" constructor is independent of the value of
a property with that name then. This is important for true emulation
because class-based inheritance implies specialization by overwriting
inherited methods which often includes calling the overwritten method before
(to perform tasks both classes have in common).

>>> So B.parentConstructor is: function Object(){}.
>> Nonsense.
>
> Allright. Who is the parent constructor of B in that case? Please
> explain.

The object referred to by `A'.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)