Useful classical inheritance example?

[-TNO-]

That's junk.  If it works at all, its working is implementation-dependent.

Good god. I need to proof-read before I submit. My apologies indeed.

 

[Thomas 'PointedEars' Lahn]

I posted this code as part of the question to the OP, to clarify what
he had in mind. I was "leading the witness" so to speak.

Your code does not satisfy the OP's explicit requirements, the key word
there being "a (node)", not "the (node)".

The keyword being "should", not "must".

So?

Please keep an attribution line for each quotation level.


PointedEars

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:

...





Your insteresting comment inspired to study a little more these typing
matters,
and I made a little newbie script about duck typing

http://www.24.fi/optimistx/clj/ducktype.htm

Duck typing gives polymorfism without inheritance(?), according to wikipedia

wikipedia about duck typing

Yep, thx for info, i know what is duck typing. It's actually related
to dynamic. The main goal is that the mutable object (with fully
possible mutations - not only value, but all characteristics) can pass
the test if it has all needed characteristics (properties/methods) *at
the moment*, which differs such mutable objects from static objects.

// in static system (e.g. Java)
if (someObject instanceof someClass) {
// some actions are allowed
}

// in dynamic system, where object can
// mutates several times per life-cycle,
// it's not essential to which class (or type)
// object it related, the position in its
// hierarchy inheritance chain also is not
// essential ('cause again - object can totally
// mutates from one type to another), so the
// test-system is only interesting in that moment -
// if object "quacks" like it's needed? in more
// correct words - if object can *answer the message*
// (itself or by delegating to its prototype - no matter)?

if (someObject.test) // ECMAScript

if someObject.respond_to?test) // Ruby

if __hasatr__(someObject, 'test'): // Python

But duck typing is not the replacement or some "version" of
inheritance, it just alternative "weak" typing - fully dynamic and
mutable. In one line object can't answer the message ".test", in the
next line it mutates (method or property ".test" has been added to
object) - and already can.

And about polymorphism - ECMAScript is polymorphic in several
meanings:

1. e.g. function could be applied to some objects as it's own method
of that objects:

function test() {
alert([this.a, this.b]);
}

test.call({a: 10, b: 20}); // 10, 20
test.call({a: 100, b: 200}); // 100, 200

var a = 1;
var b = 2;

test(); // 1, 2

Or, so called, *parametric polymorphism*, when function is one for all
types, but accepts mutable functional argument (Funarg). As example:
method ".sort" of the arrays - it accepts sort-function, but ".sort"-
method itself - is common (one interface (.sort-method), several
realizations (sort-functions) - polymorphism, and ".sort"-method is -
polymorphic).

Or, coming back to duck (weak) typing (DT), - DT - is also kind of
polymorphism, as it's doesn't matter *what type* is object, but
important can it handle some activity, important common one interface
of an object, and realizations of it can be many - again polymorphism.

The above alert(1..toString) remains mysterious for me in spite
your explanations. Two dots! Never see earlier, and that seems to 'work'.

Yep, it works. It's not a common case (just use it, 'cause
'1'.toString - makes no sense, '1' - already string ). The first dot
is used to separate the fractional part and the second one - is
already one type of the property accessors (11.2.1), dot notation, but
you know it yourself. If scanner or parser meats dot after digit, it
expects after it also digit *or* empty expression (e.g. 1., so we
should use two dots in here.

But coming back to your first question in this topic about - "for what
is (classical) inheritance needed at all?", i want to say again: first
of all - not "classical" inheritance, but native delegation based
inheritance and suggested pattern with intermediate empty function -
is just useful pattern for linking of prototypes (no more, no less).
And this system is fully and totally is in the core of ECMAScript. We
can't do not write complex objects, constructors ans so on, but can
write simple line as "1..toString()" to this *inheritance* chain and
that inheritance is in the ES before we write first line of code. And
it's *totally (and exactly) the same* as we linking our own
inheritance (prototype) chains. There's no any difference. So the
question - "for what is inheritance in ECMAScript?" - is not so
correct. Or you also need to ask this question and when see
"1..toSting" (or better, var a = 1; a.toString()), but you won't,
'cause it seems some simple expression, where there's no place for
inheritance, but in deed, in real - it's fully the same.

P.S.> sorry about mistakes and typos in words (if they are), English
is not my native language, but i'll try to write without typos

P.S.[2]> i wrote some articles about subtleties of ECMA-262-3 (http://
javascript.ru/blog/dmitry-a-soshnikov), one article (part 7) is
related to OOP paradigms where i consider the general theory of static-
class, dynamic-class and prototypical paradigms, I compare it with ES-
model, but for now it's just only in Russian language, hope will
translate it to English soon (but if, you maybe know Russian, you can
read it in origianl . There're some common information, not only
about ES, and ES is shown there from its own stage, but through a
prism of the general, common theory.

 

[-TNO-]

You should end all simple statements with a semicolon.

-TNO- wrote:
The keyword being "should", not "must".

So?

So good practice be damned for anything off the cuff.

 

[John G Harris]

...
Yes, that is a good list of information, to be used as a cheatsheet
every day!
"
Object Element
Element has the all the properties and methods of Node as well as the
properties and methods defined below.
The Element object has the following properties:
..."
But but... I do not see why and how I would need some complicated and
mysterious tricks with nodes and elements, wrestle with who would call
what and when and
pray that things turn out to work as I have imagined...

What on earth are you talking about ? To create an HTMLElement object
you just do
new HTMLElement(...)
where ... are the parameters, and Bingo!, an HTMLElement object complete
in all its glory. No more code to be added by you.

Element has all the properties of Node. So what? If I have a function

function useit(something){
if (typeof something.method1 !== 'undefined') something.method1();
} else {// ? }

and there something can be Node or Element or anything. One has
to check things there anyway (or has one?).

You seriously want to use a random method name on an object without
knowing which kind of object it is? You must be mad.

When we construct a Node or Element, we construct it, no complicated
inheritance
studies are needed, finding ancestors, cousins, grandmothers and phoning
them to ask permissions to tolk with their children or friends.( ok, a
bit exaggeration,
to create some artistic impression...).

Exactly. That's what a sensible 'new' operation does for you.

John

 

[optimistx]

What on earth are you talking about ? To create an HTMLElement object
you just do
new HTMLElement(...)
where ... are the parameters, and Bingo!, an HTMLElement object
complete in all its glory. No more code to be added by you.

In this thread 'Useful classical inheritance example' I was interested to
find an example, where the page making person CREATES
a useful hierarcical inheritance pyramide with his own javascript
code like the famous (but useless?!) example of Kevin Lindsay at

http://www.kevlindev.com/tutorials/javascript/inheritance/index.htm

In the dom example we USE the structure made by others long time ago.

When augmenting (inheriting from ?) native objects and
host objects seem to be here at least controversial (evil? impractical?),
(as might be using libraries made by others),
I start wondering, where and how would one actually create 'classes' and
'objects' (or repleace 'class' with anything you prefer) so that inheritance
is actually useful.

There is talk and recommendations about shallow inheritance
chains instead of deep. Ok, I would be very interested in
studying an example of 1-2 levels deep
actually useful example. Prototype solely as a shared repository
of some functions is not advanced enough to earn the name 'inheritance'.

Or is the talking about 'shallow inheritance' chains only therefore that
the next step 'do no construct inheritance chains at all in your code'
would not be too shocking ?

 

[Dmitry A. Soshnikov]

In this thread 'Useful classical inheritance example' I was interested to
find an example, where the page making person CREATES
a šuseful hierarcical inheritance pyramide

Please take a look what inheritance *is*, in common theory.

It's just useful *code reuse*, no more, no less.

If you want real example, take GUI system. You can build chain like
this:

Atom -> Block -> Container -> Panel -> Window and so on.

Or, with HTMLElement and its children - is also good example.

Prototype solely as a shared repository
of some functions is not advanced enough što earn the name 'inheritance'.

Why so? Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).

 

[Thomas 'PointedEars' Lahn]

[...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).

JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.

<http://docs.python.org/tutorial/classes.html#multiple-inheritance>


PointedEars

 

[John G Harris]

In this thread 'Useful classical inheritance example' I was interested to
find an example, where the page making person CREATES
a useful hierarcical inheritance pyramide with his own javascript
code like the famous (but useless?!) example of Kevin Lindsay at

http://www.kevlindev.com/tutorials/javascript/inheritance/index.htm

In the dom example we USE the structure made by others long time ago.

<snip>

At the beginning of this thread you said you hadn't found a need for
inheritance in your projects. Fair enough. Then you said you wanted to
see an example where someone did find a need for inheritance. I gave you
a well known example.

Now you say you wanted something else.

Please sit down quietly for a few minutes and then make up your mind
what you do want. Preferably not just a spurious excuse to avoid
understanding why anyone would use inheritance.

John

 

[Dmitry A. Soshnikov]

 [...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).

JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.

<http://docs.python.org/tutorial/classes.html#multiple-inheritance>

Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential. The more essential
is *mechanism of characteristic (properties/methods) resolution* -
which is very similar to ES delegation (with some assumption, it can
be treated the same). By and large, classes in Python are also can be
called as *syntactic sugar*, 'cause in deed, we see the same
delegation to "prototypes" which could be changed dynamically at any
run-time.

P.S.> and coming back to multiple inheritance, in some realizations,
as some variant of imitation __noSuchMethod__ could be used: if object
(including its prototype chain) can't answer the message, than
catching __noSuchMethod__ we can make analysis of alternative
prototype chain (of some delegate, or, even - several delegate-objects)

 

[Thomas 'PointedEars' Lahn]

[...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).

JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.

<http://docs.python.org/tutorial/classes.html#multiple-inheritance>

Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.

It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.

The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).
Hardly.

By and large, classes in Python are also can be
called as *syntactic sugar*, 'cause in deed, we see the same
delegation to "prototypes" which could be changed dynamically at any
run-time.

Everything can be called "syntactic sugar" if you tune your
vocabulary enough. THat is not in any way helpful, though.

P.S.> and coming back to multiple inheritance, in some realizations,
as some variant of imitation __noSuchMethod__ could be used: if object
(including its prototype chain) can't answer the message, than
catching __noSuchMethod__ we can make analysis of alternative
prototype chain (of some delegate, or, even - several delegate-objects)

Talk is cheap. Show me the code.
-- Linus Torvalds


PointedEars

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:
 [...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).
JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more thanone
class.
<http://docs.python.org/tutorial/classes.html#multiple-inheritance>

Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.

It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.

The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).

Hardly.

Why so? Should i show an example? Or maybe you to me, where u'll
describe why "hardly"? It's interesting to me, really.

Everything can be called "syntactic sugar"

Nope Regarding to OOP-paradigm: i think there're two major things
that could be treated as not a *sugar*, but the core principles: (1)
objects life-cycle (how they born, exist, related to other objects,
mutations of them and so on), (2) regarding to technically part:
resolution of characteristics: (a) if we have static CB-system, it
could be *unchangeable hierarchical inheritance* chain, (b) if we have
dynamic mutable objects (such as PB-system), it could be dynamic,
changeable in runtime, hierarchical (but possibly regrouped and
totally changeable) delegation chain. All the other principles and
*code reuse* methods (suc as multiple inheritance, aggregation,
mixins, traits, interfaces, abstract classes and so on) could be (but
sure, again, by and hard) as *sugar*.

if you tune your
vocabulary enough.

Thanks, i've "appreciated"

Talk is cheap.  Show me the code.
  -- Linus Torvalds

var object = {

delegates: [...],
addDelegate: function () {...},

__noSuchMethod__: function (name, args) {
alert([name, args]);
for (var k ... this.delegates ...) {
if (!(name in this.delegates[k])) {
continue;
}
return this.delegates[k][name].apply(this, args);
}
}

};

object.addDelegate({
test: function () {...},
...
});

object.addDelegate({
answerOtherMessage: function () {...},
...
});

object.test();
object.answerOtherMessage();

But, it's only my suggestion (in theoretical academic interest of
*imitation* of multiple inheritance (or, better to say - mixins, as we
creating additional objects to delegate, but no only one existing
native prototype). But if do not use words as "imitation", "multiple
inheritance", "mixins" - that's just useful way to manage dispatching
and delegating by alternative *dynamically changeable* prototype
chains (that's the main difference between static CB inheritance
chain).

/ds

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
[...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).
JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.
<http://docs.python.org/tutorial/classes.html#multiple-inheritance>
Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.

It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.

The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).

Hardly.

Why so? Should i show an example? Or maybe you to me, where u'll
describe why "hardly"? It's interesting to me, really.

Maybe later. Maybe elsewhere. Comparing programming languages is not
on-topic here if not both are ECMAScript implementations.

Talk is cheap. Show me the code.
-- Linus Torvalds

var object = {

delegates: [...],
addDelegate: function () {...},

__noSuchMethod__: function (name, args) {
alert([name, args]);
for (var k ... this.delegates ...) {
if (!(name in this.delegates[k])) {
continue;
}
return this.delegates[k][name].apply(this, args);
}
}

};

object.addDelegate({
test: function () {...},
...
});

object.addDelegate({
answerOtherMessage: function () {...},
...
});

object.test();
object.answerOtherMessage();

Thanks. I had no doubt that the __noSuchMethod__() method could be written;
but your code avoids the issue by not answering to your premise: how do you
trigger it? As you do not know which properties may be accessed, the
`addDelegate' does not help. So you would need to intercept property
lookup; that means you either have to rewrite the implementation, or you
catch the exception, or you have to use an explicit getter and setter for
each property that calls __noSuchMethod()__ when necessary. By which,
incidentally, we are back to encapsulation and why I think the definitions
you gave here are either too widely or too narrowly thought.


PointedEars

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:
Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
 [...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).
JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.
<http://docs.python.org/tutorial/classes.html#multiple-inheritance>
Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.
It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.
<http://www.python.org/download/releases/2.3/mro/>
The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).
Hardly.

Why so? Should i show an example? Or maybe you to me, where u'll
describe why "hardly"? It's interesting to me, really.

Maybe later.  Maybe elsewhere.  Comparing programming languagesis not
on-topic here if not both are ECMAScript implementations.

Your choice, I do not insist. But that two things are different: (1)
you *don't wanna* comparing languages and see the general common
theory, and (2) comparing languages is on topic (as we've mentioned
general theory but not only ECMA-262 technology But if it will be
interesting to you, i show you an example later.

var object = {

  delegates: [...],
  addDelegate: function () {...},

  __noSuchMethod__: function (name, args) {
    alert([name, args]);
    for (var k ... this.delegates ...) {
      if (!(name in this.delegates[k])) {
        continue;
      }
      return this.delegates[k][name].apply(this, args);
    }
  }

};

object.addDelegate({
  test: function () {...},
  ...
});

object.addDelegate({
  answerOtherMessage: function () {...},
  ...
});

object.test();
object.answerOtherMessage();

Thanks.  I had no doubt that the __noSuchMethod__() method could be written;
but your code avoids the issue by not answering to your premise: how do you
trigger it?

__noSuchMethod__ is common office signal (message) which is caught
when object can't answer the message itself (including its prototype
chain). This signal is trigger *automatically* (did you try to run
this example? try e.g. in SpiderMonkey and u'll see how it works).
It's general signal in general theory of dynamic objects and is in
some realizations: e.g.:

- #doesNotUnderstand (SmallTalk);
- method_missing (Ruby)
- __getattr__ (Python)
- __call (PHP)
- __noSuchMethod__ (some ECMAScript realizations, e.g. SpiderMonkey)
- and so on.

Sure it's not standard method, ECMA-262-3 says nothing about that,
that's why i mentioned that it's just theoretical academical interest
of that imitation

/ds

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
[...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).
JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.
<http://docs.python.org/tutorial/classes.html#multiple-inheritance>
Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.
It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.
<http://www.python.org/download/releases/2.3/mro/>
The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).
Hardly.
Why so? Should i show an example? Or maybe you to me, where u'll
describe why "hardly"? It's interesting to me, really.

Maybe later. Maybe elsewhere. Comparing programming languages is not
on-topic here if not both are ECMAScript implementations.

Your choice, I do not insist. But that two things are different: (1)
you *don't wanna* comparing languages and see the general common
theory,

What the heck are you talking about?

and (2) comparing languages is on topic

Not here, unless both languages are ECMAScript implementations.

(as we've mentioned

general theory but not only ECMA-262 technology

Your ignoring the topic of this newsgroup does not make these discussions
on-topic here.

But if it will be interesting to you, i show you an example later.

(Cross-posted with Followup-To) elsewhere (comp.lang.misc), please.

__noSuchMethod__ is common office signal (message) which is caught
when object can't answer the message itself (including its prototype
chain). This signal is trigger *automatically* (did you try to run
this example?

It wasn't executable verbatim, so no(t yet).

try e.g. in SpiderMonkey and u'll see how it works).
It's general signal in general theory of dynamic objects and is in
some realizations: e.g.:

- #doesNotUnderstand (SmallTalk);
- method_missing (Ruby)
- __getattr__ (Python)
- __call (PHP)
- __noSuchMethod__ (some ECMAScript realizations, e.g. SpiderMonkey)
- and so on.

Sure it's not standard method, ECMA-262-3 says nothing about that,
that's why i mentioned that it's just theoretical academical interest
of that imitation

Thanks for that, then.


PointedEars

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:
Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
Thomas 'PointedEars' Lahn wrote:
Dmitry A. Soshnikov wrote:
 [...] Again, in ECMAScript there *is* inheritance - based on
delegation to prototypes. Try to find difference between Python's
class inheritance chain (it was not casually that i mentioned it above
and even showed full example).
JFTR: The better word to describe Python's inheritance mechanism is "net",
because it supports multiple inheritance -- inheritance from more than one
class.
<http://docs.python.org/tutorial/classes.html#multiple-inheritance>
Yeah, thx, i know about inheritance model used in Python. But,
multiple inheritance is just also additional code reuse *sugar* (yeah,
really, if we can reuse code from one class, why do not do that from
ten classes? - that's OK). It's not so essential.
It was essential enough to completely rewrite the MRO from Python 2.2 to
Python 2.3.
<http://www.python.org/download/releases/2.3/mro/>
The more essential is *mechanism of characteristic (properties/methods)
resolution* - which is very similar to ES delegation (with some
assumption, it can be treated the same).
Hardly.
Why so? Should i show an example? Or maybe you to me, where u'll
describe why "hardly"? It's interesting to me, really.
Maybe later.  Maybe elsewhere.  Comparing programming languages is not
on-topic here if not both are ECMAScript implementations.

Your choice, I do not insist. But that two things are different: (1)
you *don't wanna* comparing languages and see the general common
theory,

What the heck are you talking about?

hey, take it easy, man it's just discussion, conversation. If
there's nothing to say, then don't say.

Not here, unless both languages are ECMAScript implementations.

(as we've mentioned


Your ignoring the topic of this newsgroup does not make these discussions
on-topic here.

Are you too limited to see hardly further and deeper? I'm not ignoring
the topic, just answer the questions which are go to the left and to
the right from the direct way of the first description of the topic. I
repeat, if u don't wanna to answer - it's very easy - then do not do
that. But if u're interested in ES, than it seems to me a little bit
strange that u don't wanna discuss independent theory (but used in
ES). I do not insist, your choice, repeat again

(Cross-posted with Followup-To) elsewhere (comp.lang.misc), please.

Why so? Sorry, who r u to send me to the .misc? I'm talking about
ECMAScript and show u the general independent principles (by making
parallel with other technology, e.g. Python). If it's not interesting
to you, just don't' answer, that's simple.

It wasn't executable verbatim, so no(t yet).

ah, i thought u good enough in ES to complete this sample code
yourself to be executable, sorry; i just showed most important part.

Thanks for that, then.

you're welcome

 

[Thomas 'PointedEars' Lahn]

hey, take it easy, man it's just discussion, conversation. If
there's nothing to say, then don't say.

You should follow your own advice.

Are you too limited to see hardly further and deeper?

Are you too limited to accept that issues concerning more than one (group
of) languages are not on-topic in a newsgroup dedicated to only one (group
of) language(s)?

Why so? Sorry, who r u to send me to the .misc?

Former question withdrawn.

(Who are you, to post to a newsgroup in a chat style?) I am a subscriber to
this newsgroup who wants to read and discuss here about things that belong
here. I am not sending you anywhere (well, now I am sending you to my
scorefile. Congratulations.)


PointedEars

 

[Dmitry A. Soshnikov]

(Who are you, to post to a newsgroup in a chat style?)

k, i can't impose the knowledge to you, if you don't wanna understand,
how can i insist on it? your choice, simple don't read what i
write.

well, now I am sending you to my
scorefile.  Congratulations.

As you wish, no matter for me. Really. But in the next time try to
think and to discuss with more scientific approach and with the wish
to understand; learn ES (and sure, common general theory to be next
time more trained in that). Thx for conversation.

/ds

 

[Thomas 'PointedEars' Lahn]

I don't know exact semantics of `responds_to?` in Ruby or `__hasatr__`
in Python, but I have a feeling they don't care about value of a
property in question.

At least Python's hasattr() does not care about the value of the attribute.

`in` operator would give a better indication of whether property is
present in object or its prototype chain.

`Object.prototype.hasOwnProperty` method would give a better indication
of whether property is present on an object itself.

Unless it is a host object. Both are not backwards-compatible, too.

<http://PointedEars.de/es-matrix#i>
<http://PointedEars.de/es-matrix#o>


PointedEars

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote: [...]
http://www.24.fi/optimistx/clj/ducktype.htm
Duck typing gives polymorfism without inheritance(?), according to wikipedia
wikipedia about duck typing

Yep, thx for info, i know what is duck typing. It's actually related
to dynamic. The main goal is that the mutable object (with fully
possible mutations - not only value, but all characteristics) can pass
the test if it has all needed characteristics (properties/methods) *at
the moment*, which differs such mutable objects from static objects.

// in static system (e.g. Java)
if (someObject instanceof someClass) {
  // some actions are allowed
}

// in dynamic system, where object can
// mutates several times per life-cycle,
// it's not essential to which class (or type)
// object it related, the position in its
// hierarchy inheritance chain also is not
// essential ('cause again - object can totally
// mutates from one type to another), so the
// test-system is only interesting in that moment -
// if object "quacks" like it's needed? in more
// correct words - if object can *answer the message*
// (itself or by delegating to its prototype - no matter)?

if (someObject.test) // ECMAScript

That's not a very good test for a *presence* of property

I don't know exact semantics of `responds_to?` in Ruby or `__hasatr__`
in Python, but I have a feeling they don't care about value of a
property in question.

`in` operator would give a better indication of whether property is
present in object or its prototype chain.

`Object.prototype.hasOwnProperty` method would give a better indication
of whether property is present on an object itself.

if someObject.respond_to?test) // Ruby

if __hasatr__(someObject, 'test'): // Python

[...]

Yeah, thanks, I know about that, just mentioned in example of duck
typing. About that check wrote myself in article of OOP in ECMAScript
<http://javascript.ru/blog/Dmitry-A.-Soshnikov/Tonkosti-ECMA-262-3.-
CHast-7.-OOP.#metod-get>, there only in Russian language yet, will
translate it later maybe, but you can see the source code examples.