Not understanding OOP stuff

[bit-n...@hotmail.com]

Hi,
I had posted a question here previously, but I was away for some time and didn't check the replies,... anyway, I had posted a question about AJAX, and "JJ" posted this in reply (thanks, btw :) ), which I don't understand:


var xhr = new XMLHttpRequest();
xhr.addEventListener("load", function() { ... <blah>


I don't get it. What does the above code mean? "new XMLHttpRequest()" returns an object right? Is "addEventListener" INSIDE it or something? How is that possible?


Btw, can addEventListener have a "hover" first-argument?


Thanks.

[JJ]

For mouse hover event, use "mouseenter" or "mouseover" event. Both are
similar but not the same.

<https://developer.mozilla.org/en-US/docs/Web/Events/mouseenter>

<https://developer.mozilla.org/en-US/docs/Web/Events/mouseover>

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> bit-n...@hotmail.com writes:
>> Is "addEventListener" INSIDE it or something? How is that possible?
>

> Yes.

N-O.

> Objects can contain methods.

N-O. Objects *in ECMAScript implementations* can have *properties* whose
value is a reference to a callable object; those are called “methods”. But
this object does not even have such a property; it *inherits* it from
another object, its prototype (or the prototype of that, depending on the
DOM implementation). The main reason for that is reusability and
consistency; objects that have the same object as their prototype can make
use of the same method, and as the method implements a specific algorithm,
of the same algorithm. This allows them to perform equal or at least
similar functions.

> (At least, this is the common metaphor.)

Programming is _not_ philosophy. You would be well-advised to not speak in
metaphors with regard to programming, but to learn and utilize precise
terminology as well as the basic concepts of these programming languages
before you attempt to teach them. Probably someone has told you this
before.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[Julio Di Egidio]

On Sunday, July 23, 2017 at 6:12:22 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
<snip>

> > (At least, this is the common metaphor.)
>
> Programming is _not_ philosophy.

Agreed: and, crucially, JavaScript is _not_ an object-oriented language.

Julio

[Ben Bacarisse]

From ECMA 262:

"ECMAScript is an object-oriented programming language..."

Maybe one could call the point "debatable"? (Not that I want to debate
it.)

--
Ben.

[Julio Di Egidio]

It may be debatable, it certainly is debated, but I think it's total
nonsense and essentially a consequence of the so called "OO uber alles".
Also, you have already been warned that the JS standard does have few
problems: supporting confusion on the very paradigm is one of them.

JavaScript is a *functional* language, just with specific support for
"objects" and prototypal inheritance: some call it "object-based" instead
of "object-oriented" in order to name that distinction.

In fact, that one can build a fully OO abstraction on top of JS means that
the language is super-powerful, not that anyone should really go for any
such aberrations. Not any more than one should map relational data to
objects, which is the other side of the coin of the same OO uber alles
nonsense. Another important point being, at the architectural level,
that it's functional the most naturally modular, not OO: indeed OO is the
least modular, and literally the least in many other respects.

And so on, about OO abuse vs what is not OO: the bottom line remaining that
JS is essentially functional and that it is important to understand that.

Julio

[Thomas 'PointedEars' Lahn]

Only if one would be so un(der)educated as to not know that the
implementation of the object-oriented paradigm does not require *class-
based* inheritance. Then not even Self, one of the first object-oriented
programming languages (influenced only by Smalltalk, and one of the
influences of Netscape JavaScript, origin of the current landscape of
ECMAScript implementations) would be one.

But several programming languages that have JavaScript in their name
(“JavaScripts”), including some usable in Web browsers, even have native
classes now. (Formerly, only Netscape JavaScript 2.0 [experimental],
JScript .NET, and ActionScript 2.0+ had native classes, based on Netscape’s
abandoned ECMAScript Ed. 4 proposal. In implementations that have not, user
code can be used to emulate class-based inheritance; see, among others, my
JSX:object.js:Function.prototype.extend().)

All JavaScripts are (*at their face* and *according to their vendors*)
(conforming) implementations of ECMAScript, and provide all features that
make a programming language an object-oriented one.

<https://en.wikipedia.org/wiki/Object-oriented_programming>

Only trolls and wannabes would say otherwise (here). Please do not feed.

[Julio Di Egidio]

You are an incompetent moron, now regurgitating a bit of the very nonsense
and hype I was mentioning. Anyone interested in such debate, just try and
find one property of functional languages that JS does not have. EOD.

Julio

[Ben Bacarisse]

Julio Di Egidio <ju...@diegidio.name> writes:

> On Sunday, July 23, 2017 at 9:10:58 PM UTC+2, Ben Bacarisse wrote:
>> Julio Di Egidio <ju...@diegidio.name> writes:
>> > On Sunday, July 23, 2017 at 6:12:22 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
>> >> Stefan Ram wrote:
>> > <snip>
>> >> > (At least, this is the common metaphor.)
>> >>
>> >> Programming is _not_ philosophy.
>> >
>> > Agreed: and, crucially, JavaScript is _not_ an object-oriented
>> > language.
>>
>> From ECMA 262:
>>
>> "ECMAScript is an object-oriented programming language..."
>>
>> Maybe one could call the point "debatable"? (Not that I want to debate
>> it.)
>
> It may be debatable, it certainly is debated, but I think it's total
> nonsense and essentially a consequence of the so called "OO uber alles".
> Also, you have already been warned that the JS standard does have few
> problems: supporting confusion on the very paradigm is one of them.

The interesting things are the concepts not the names. ECMAScript
supports many of the concepts that people like Alan Kay would say are
essential to being object-oriented. It supports local retention and
hiding of state along with extreme late binding, but it does not use
message passing as the communication between objects. (And the hiding
of state is not enforced.)

> JavaScript is a *functional* language, just with specific support for
> "objects" and prototypal inheritance: some call it "object-based" instead
> of "object-oriented" in order to name that distinction.

Taking a cue from you, I'd rather say that it supports functional
programming. A language that has mutable state, and in which that state
is so often used in idiomatic code, has a rather weak claim to be called
a functional language.

> In fact, that one can build a fully OO abstraction on top of JS means that
> the language is super-powerful, not that anyone should really go for any
> such aberrations.

Right, but that's always going end up in a logical hole. What matters
is what is directly supported by the language and what typical code
really does. For example, F# and SML both have mutable "variables", but
they are so rarely used in idiomatic code that this does not usually
prevent them from being called "functional".

<snip>
--
Ben.

[Julio Di Egidio]

On Sunday, July 23, 2017 at 11:04:01 PM UTC+2, Ben Bacarisse wrote:

> Taking a cue from you, I'd rather say that it supports functional
> programming.

And you'd have it exactly up-side down, as customary for the industry.

And based on pure unreasonability: 1) I have mentioned that JS is that
powerful and more, so the invalid reduction is all yours; 2) I have
challenged you to find something that makes JS not *essentially functional*,
and I'd expect you in particular (and anyone chiming in with claims) to know
that "essentially functional" is precise enough that we can give a definite
answer to that question.

The one relevant cue here is: get serious or get lost.

Julio

[Ben Bacarisse]

Julio Di Egidio <ju...@diegidio.name> writes:

> On Sunday, July 23, 2017 at 11:04:01 PM UTC+2, Ben Bacarisse wrote:
>
>> Taking a cue from you, I'd rather say that it supports functional
>> programming.
>
> And you'd have it exactly up-side down, as customary for the industry.
>
> And based on pure unreasonability: 1) I have mentioned that JS is that
> powerful and more, so the invalid reduction is all yours;

I don't think anyone has disagreed that one can do functional
programming in ECMAScript. (If that's what you mean by it being "that
powerful".)

> 2) I have
> challenged you to find something that makes JS not *essentially functional*,
> and I'd expect you in particular (and anyone chiming in with claims) to know
> that "essentially functional" is precise enough that we can give a definite
> answer to that question.

When did you so challenge me?

As it happens, I explained exactly why ECMAScript is not essentially
functional in the text you've just edited -- the presence and idiomatic
use of mutable state.

Since only you know exactly what is need for a language to meet your
definition, you would have advanced the exchange more fruitfully by
explaining *why* you disagree. *That* you disagree can be taken for
granted.

<snip>
--
Ben.

[Ben Bacarisse]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>The interesting things are the concepts not the names. ECMAScript
>>supports many of the concepts that people like Alan Kay would say are
>>essential to being object-oriented. It supports local retention and
>>hiding of state along with extreme late binding, but it does not use

>>message passing as the communication between objects.¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> Why can't I say that when the JavaScript expression
>
> o.m()
>
> is being evaluated, "the call message »m()« is being
> sent to the object »o«"¹?

You certainly can. I don't like to say that but it's very far from
being objectively wrong to do so.

> How do you define »message passing«, and which part
> of your definition is not fulfilled by ECMAScript?

For me, a message should be a thing in itself (in Smalltalk messages
are, conceptually, objects though almost always optimised away). You
should be able, when required, to build one at run-time and store it for
later sending to an object. A natural consequence of that would be
the ability of an object to forward a message to some other object.

<snip>
--
Ben.

[Julio Di Egidio]

You are not just a dishonest interlocutor, you are truly retarded.

*Plonk*

Julio

[Julio Di Egidio]

<https://youtu.be/QM1iUe6IofM>

Which is just scratching the surface...

Lesson #1 is that CS is not SE, and lesson #2 is that you don't know shit
about either.

Julio

[Thomas 'PointedEars' Lahn]

Stefan Ram wrote:

> It is possible that ECMAScript does not contain the
> word »message« in this sense, but UML provides this
> vocabulary with a meaning that might be applicable
> to JavaScript.

Indeed, that one *can* draw proper UML 2 diagrams for programs (to be)
written in ECMAScript-based programming languages (at least class diagrams,
sequence diagrams, and communication diagrams; I have posted several of the
first ones here[1]) is another indication that they *are* object-oriented.

<https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams>

____________
[1] e.g., in
<news:5769635.4...@PointedEars.de>
<news:3306468.k...@PointedEars.de>
<news:3160292.R...@PointedEars.de>

[Thomas 'PointedEars' Lahn]

Ben Bacarisse wrote:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>>The interesting things are the concepts not the names. ECMAScript
>>>supports many of the concepts that people like Alan Kay would say are
>>>essential to being object-oriented. It supports local retention and
>>>hiding of state along with extreme late binding, but it does not use
>>>message passing as the communication between objects.¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>> Why can't I say that when the JavaScript expression
>>
>> o.m()
>>
>> is being evaluated, "the call message »m()« is being
>> sent to the object »o«"¹?
>
> You certainly can. I don't like to say that but it's very far from
> being objectively wrong to do so.

ACK.

>> How do you define »message passing«, and which part
>> of your definition is not fulfilled by ECMAScript?
>
> For me, a message should be a thing in itself (in Smalltalk messages
> are, conceptually, objects though almost always optimised away). You
> should be able, when required, to build one at run-time and store it for
> later sending to an object.

That is possible in ECMAScript implementations:

var f = function (/* … */) { /* … */ };
var o = {};
o.foo = f;
o.foo();

> A natural consequence of that would be the ability of an object to forward
> a message to some other object.

That is also possible in ECMAScript implementations:

var o2 = {};
o2.bar = o.foo;
o2.bar();

var o3 = {};
o2.foo.call(o3, 42, 23);
o2.foo.apply(o3, [42, 23]);

The Editions of the ECMAScript Language Specification refer to this as
“transferred to other kinds of objects for use as a method”. Built-in
functions/methods that allow this are described as being “intentionally
generic; it does not require that its ‘this’ value be an [object type]
object.” ([ES2016], §§ 20.1.3.6, 20.3.4.37, 20.3.4.41, 21.1.3.1, etc.)

[ES2016] <http://www.ecma-international.org/ecma-262/7.0/>

[Julio Di Egidio]

On Monday, July 24, 2017 at 10:33:42 AM UTC+2, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>
> > It is possible that ECMAScript does not contain the
> > word »message« in this sense, but UML provides this
> > vocabulary with a meaning that might be applicable
> > to JavaScript.
>
> Indeed, that one *can* draw proper UML 2 diagrams for programs (to be)
> written in ECMAScript-based programming languages (at least class diagrams,
> sequence diagrams, and communication diagrams; I have posted several of the
> first ones here[1]) is another indication that they *are* object-oriented.
>
> <https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams>

UML is problematic indeed because it is too much stuck onto OO constructs.
That said, that one can use some UML even when the language is JS is utterly
trivial as well as another nonsensical argument in support of JS being OO.

As said, you guys just don't know what you are talking about, all you do
is echo widespread nonsense.

Julio

[John G Harris]

On Sun, 23 Jul 2017 18:12:10 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

>Stefan Ram wrote:
>
>> bit-n...@hotmail.com writes:
>>> Is "addEventListener" INSIDE it or something? How is that possible?
>>
>> Yes.
>
>N-O.
>
>> Objects can contain methods.
>
>N-O.

We all know that software does not have insides and outsides. But
software can implement conceptual things that do have insides and
outsides. If anyone wants to think of an ECMAScript object as
something that contains properties then they are not wrong. What would
be wrong is criticising them for this view.

>Objects *in ECMAScript implementations* can have *properties* whose
>value is a reference to a callable object;

... whose value is an object with a [[Call]] internal method; ...

Please use the terminology specified in ECMA 262.

John

[John G Harris]

On Sun, 23 Jul 2017 12:42:08 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:

>On Sunday, July 23, 2017 at 9:10:58 PM UTC+2, Ben Bacarisse wrote:

<snip>

>> "ECMAScript is an object-oriented programming language..."

<snip>
>JavaScript is a *functional* language
<snip>

And so is C++.

ECMAScript is an OO language. And so is C++.

ECMAScript is a procedural language. And so is C++.

In other words, both languages can be used in different ways, whatever
suits the problem and the programmer. If you want to be posh you say
they are multi-paradigm languages.

John

[John G Harris]

On Sun, 23 Jul 2017 22:42:55 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>

>user
>code can be used to emulate class-based inheritance;

<snip>

Strange. You, Thomas, have furiously denied that in the past.

John

[Julio Di Egidio]

On Monday, July 24, 2017 at 12:16:01 PM UTC+2, John G Harris wrote:
> On Sun, 23 Jul 2017 12:42:08 -0700 (PDT), Julio Di Egidio
> <ju...@diegidio.name> wrote:
> >On Sunday, July 23, 2017 at 9:10:58 PM UTC+2, Ben Bacarisse wrote:
> <snip>
> >> "ECMAScript is an object-oriented programming language..."
> <snip>
> >JavaScript is a *functional* language
> <snip>
>
> And so is C++.

No, C++ is certainly not a functional language.

> ECMAScript is an OO language.

Nope, neither.

> ECMAScript is a procedural language. And so is C++.

And not even that: "procedural" is at a different level of abstraction
altogether, indeed it is agnostic to the language paradigms, it's about
how one architects code at the high level... The link I have given up-
thread explains what "procedural" means.

> In other words, both languages can be used in different ways, whatever
> suits the problem and the programmer. If you want to be posh you say
> they are multi-paradigm languages.

But it is not a matter of opinions, nor the terminology is just casual.
And then again, that JS is "essentially functional" is first of all a
fact and then an important point, in that having clear ideas helps the
programmer structure code sensibly. Conversely, the loss is not just
"theoretical".

Building software is the most complex engineering that there is...

Julio

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> […] user code can be used to emulate class-based inheritance;

>
> Strange. You, Thomas, have furiously denied that in the past.

No, I have not.

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> On Sun, 23 Jul 2017 18:12:10 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>>Stefan Ram wrote:
>>> bit-n...@hotmail.com writes:
>>>> Is "addEventListener" INSIDE it or something? How is that possible?
>>>
>>> Yes.
>>
>>N-O.
>>
>>> Objects can contain methods.
>>
>>N-O.
>
> We all know that software does not have insides and outsides. But
> software can implement conceptual things that do have insides and
> outsides. If anyone wants to think of an ECMAScript object as
> something that contains properties then they are not wrong. What would
> be wrong is criticising them for this view.

There is a difference between saying “an object contains a property” and
“an object contains a method”.

In ECMAScript 2016, § “4.2 ECMAScript Overview”:

,-<http://www.ecma-international.org/ecma-262/7.0/#sec-ecmascript-overview>
|
| […] a function is a callable object. A function that is associated with
^^^^^^^^^^^^^^^
| an object via a property is called a /method/.
|
| […]
| 4.3.30 property
|
| part of an object that associates a key (either a String value or a Symbol
| value) and a value
| […]
|
| 4.3.31 method
|
| function that is the value of a property
| […]

Section 4 “contains a non-normative overview of the ECMAScript Language”,
but there are no other explicit definitions for “method” in any Edition of
the Specification, so this is as best as it gets.

However, given the number of occurrences where it is being said that an
object “_has_ a property”, including names such as “hasOwnProperty”,
I (among others) prefer and recommend to use *that* wording instead.

[The same goes for “references”: the fact that the modification of the
properties of an object #1 can simultaneously affect the properties of
two distinct other objects #2 and #3 is easier to understand if one
does not assume that object #1 is the value of both the property of
objects #2 and #3, and somehow object #1 is contained in both objects
#2 and #3, but is being referred to by the value of their properties
(reference value). Which also comes closer to what is mostly being
implemented (a property name maps to a pointer value referring a memory
area where object data is stored).]

>> Objects *in ECMAScript implementations* can have *properties* whose
>> value is a reference to a callable object;
>
> ... whose value is an object with a [[Call]] internal method; ...
>
> Please use the terminology specified in ECMA 262.

You do not know “ECMA 262” as well as you think you do (you do not even know
that it is properly written _ECMA-262_, and then the term is still imprecise
due to the several Editions).

The term “callable object” is not my invention. See above, and e.g.
ECMAScript 2016, § “6.1.7.2 Object Internal Methods and Internal Slots”:

,-<http://www.ecma-international.org/ecma-262/7.0/#table-6>
|
| Table 6: Additional Essential Internal Methods of Function Objects
|
| Internal Method Signature Description
| ------------------------------------------------------------------------
| [[Call]] (any, a List of any) → any Executes code associated
| with this object. Invoked
| via a function call
| expression. The arguments
| to the internal method are
| a *this* value and a list
| containing the arguments
| passed to the function by
| a call expression. Objects
^^^^^^^^^^^^^^^^^^^^^^^^^^
| that implement this
^^^^^^^^^^^^^^^^^^^
| internal method are
^^^^^^^^^^^^^^^^^^^
| /callable/.
^^^^^^^^^^^

Moreover, you have failed to realize that those internal methods and slots
are purely specification mechanisms:

| 6.1.7.2 Object Internal Methods and Internal Slots
|
| The actual semantics of objects, in ECMAScript, are specified via
| algorithms called internal methods. Each object in an ECMAScript engine is
| associated with a set of internal methods that defines its runtime
| behaviour. These internal methods are not part of the ECMAScript language.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| They are defined by this specification purely for expository purposes.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| However, each object within an implementation of ECMAScript must behave as
| specified by the internal methods associated with it. The exact manner in
| which this is accomplished is determined by the implementation.

(*That* section, “6 ECMAScript Data Types and Values”, *is* normative.)

[Michael Haufe (TNO)]

Julio Di Egidio wrote:

> Agreed: and, crucially, JavaScript is _not_ an object-oriented language.

The generally accepted definition of OOP is described by Benjamin Pierce in TAPL [1][2]. Namely:

1. Multiple representations: The object dictates what code is
executed, often at runtime using dynamic dispatch
2. Encapsulation: Hiding of internal representation and providing a
limited interface for access.
3. Subtyping: Interface sharing
4. Inheritance: Implementation sharing of shared interfaces.
Generally done through classes or delegation
5. Open recursion: The ability of a method to refer to other methods
of itself before/after they are defined. (keyword 'this' in JS, 'self'
in Python, 'my' in Perl, etc.)


So JavaScript is "Object-Oriented" because it has a set of features in common with the definition of being Object Oriented.


[1] <https://www.cis.upenn.edu/~bcpierce/tapl/>
[2] See Chapter 18.1 <http://port70.net/~nsz/articles/book/pierce_types_and_programming_languages_2002.pdf>

[Julio Di Egidio]

On Monday, July 24, 2017 at 7:20:26 PM UTC+2, Michael Haufe (TNO) wrote:
> Julio Di Egidio wrote:
>
> > Agreed: and, crucially, JavaScript is _not_ an object-oriented language.
>
> The generally accepted definition of OOP is described by Benjamin Pierce
> in TAPL [1][2]. Namely:
>
> 1. Multiple representations: The object dictates what code is
> executed, often at runtime using dynamic dispatch
> 2. Encapsulation: Hiding of internal representation and providing a
> limited interface for access.
> 3. Subtyping: Interface sharing
> 4. Inheritance: Implementation sharing of shared interfaces.
> Generally done through classes or delegation
> 5. Open recursion: The ability of a method to refer to other methods
> of itself before/after they are defined. (keyword 'this' in JS, 'self'
> in Python, 'my' in Perl, etc.)
>
> So JavaScript is "Object-Oriented" because it has a set of features in
> common with the definition of being Object Oriented.

That's just more utter bullshit, where you guys do not understand the
actual technical meaning of even the most basic definitions.

But now I am done with the explanations, who wants to get get will get it,
the rest of morons and polluters and wannabees just thanks for making the
world the shithole for everybody that is it. (Fuck you.)

*Plonk*

Julio

[John G Harris]

On Sun, 23 Jul 2017 21:50:06 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:


<snip>
><https://youtu.be/QM1iUe6IofM>
<snip>

The title of that video is "Object-Oriented Programming is Bad" but
this is rather misleading. The author approves of using
classes/objects for such things as stacks, trees, complex numbers, and
dates.

In summary, he advocates using OO languages sensibly. Quel surprise!

John

[Julio Di Egidio]

On Monday, July 24, 2017 at 8:50:19 PM UTC+2, John G Harris wrote:
> On Sun, 23 Jul 2017 21:50:06 -0700 (PDT), Julio Di Egidio
> <ju...@diegidio.name> wrote:
>
> <snip>
> ><https://youtu.be/QM1iUe6IofM>
> <snip>
>
> The title of that video is "Object-Oriented Programming is Bad" but
> this is rather misleading. The author approves of using
> classes/objects for such things as stacks, trees, complex numbers, and
> dates.

Because those are inherently data-structures, you moron!

> In summary, he advocates using OO languages sensibly. Quel surprise!

In summary, you have not understood the first thing about what's said
there: and how is that a surprise? It's software engineering, with its
own discipline and terminology, while you guys are just a bunch of
bullshit regurgitators and life hijackers, and not even any honest at
that...

Julio

[Ben Bacarisse]

(Did you mean o.foo or o2.bar here?)

That's not really what I mean because because there is no "thing" (I
want to avoid saying object here) that is the message. By making the
message a think in its own right, message passing systems can disconnect
the message from the method that implements it. That's all part of the
late binding that some people consider so important.

For example, in a message passing language the message can fail if the
object does not implement that particular message. In your examples,
the message sending (which is just a function call) can't fail for that
reason.

To my mind, message passing would look rather more like:

var msg = ["foo", 42, 23];
o.process_message(msg);

This would succeed or fail depending on whether o's prototype chain
included a foo method at that time.

<snip>
--
Ben.

[John G Harris]

On Tue, 25 Jul 2017 00:09:20 +0100, Ben Bacarisse
<ben.u...@bsb.me.uk> wrote:

<snip>

>For example, in a message passing language the message can fail if the
>object does not implement that particular message. In your examples,
>the message sending (which is just a function call) can't fail for that
>reason.
>
>To my mind, message passing would look rather more like:
>
> var msg = ["foo", 42, 23];
> o.process_message(msg);
>
>This would succeed or fail depending on whether o's prototype chain
>included a foo method at that time.

Surely doing a.foo() will fail if a and its prototype chain don't
implement the foo kind of message.

In most other languages it's the compiler that will do the failing,
but these are really all the same thing : fail if the 'message' is not
understood.

John

[John G Harris]

On Mon, 24 Jul 2017 12:00:06 -0700 (PDT), Julio Di Egidio

<ju...@diegidio.name> wrote:

>On Monday, July 24, 2017 at 8:50:19 PM UTC+2, John G Harris wrote:
>> On Sun, 23 Jul 2017 21:50:06 -0700 (PDT), Julio Di Egidio
>> <ju...@diegidio.name> wrote:
>>
>> <snip>
>> ><https://youtu.be/QM1iUe6IofM>
>> <snip>
>>
>> The title of that video is "Object-Oriented Programming is Bad" but
>> this is rather misleading. The author approves of using
>> classes/objects for such things as stacks, trees, complex numbers, and
>> dates.
>
>Because those are inherently data-structures, you moron!

So you agree that OO is good for some things.

>> In summary, he advocates using OO languages sensibly. Quel surprise!

>In summary, you have not understood the first thing about what's said
>there: and how is that a surprise? It's software engineering, with its
>own discipline and terminology, while you guys are just a bunch of
>bullshit regurgitators and life hijackers, and not even any honest at
>that...

We are getting the impression that you prefer abuse to coherent
argument.

John

[John G Harris]

On Mon, 24 Jul 2017 03:58:13 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:

<snip>

>No, C++ is certainly not a functional language.

Then neither is ECMAScript : both languages have first-class function
objects.


<snip>

>Building software is the most complex engineering that there is...

"as" complex, but not "most" : compare with the Apollo moon landing
hardware, the world's telephone system, and a CPU floating point unit.

John

[Ben Bacarisse]

John G Harris <ni...@jghnorth.org.uk.invalid> writes:

> On Tue, 25 Jul 2017 00:09:20 +0100, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
> <snip>
>>For example, in a message passing language the message can fail if the
>>object does not implement that particular message. In your examples,
>>the message sending (which is just a function call) can't fail for that
>>reason.
>>
>>To my mind, message passing would look rather more like:
>>
>> var msg = ["foo", 42, 23];
>> o.process_message(msg);
>>
>>This would succeed or fail depending on whether o's prototype chain
>>included a foo method at that time.
>
> Surely doing a.foo() will fail if a and its prototype chain don't
> implement the foo kind of message.

The suggested code included a.foo = <some function>.

<snip>
--
Ben.

[Michael Haufe (TNO)]

Julio Di Egidio wrote:

> Michael Haufe (TNO) wrote:

> > So JavaScript is "Object-Oriented" because it has a set of features in
> > common with the definition of being Object Oriented.
>
> That's just more utter bullshit, where you guys do not understand the
> actual technical meaning of even the most basic definitions.

Pray tell. The fact that you used the term "technical meaning" in this context belies your knowledge of the subject I think...

[Julio Di Egidio]

On Tuesday, July 25, 2017 at 10:29:25 AM UTC+2, John G Harris wrote:
> On Mon, 24 Jul 2017 12:00:06 -0700 (PDT), Julio Di Egidio

<snip>

> >Because those are inherently data-structures, you moron!
>
> So you agree that OO is good for some things.

I have never said otherwise: OO uber alles is an aberration,
and its converse, that everything is equal to everything.

> We are getting the impression that you prefer abuse to coherent
> argument.

"You" are a bunch of morons and liars, and I know it's wasted on you, who
wouldn't recognise an argument not even if it was offered by God in person:
you monsters can't even really read...

Julio

[Julio Di Egidio]

On Tuesday, July 25, 2017 at 10:42:57 AM UTC+2, John G Harris wrote:
> On Mon, 24 Jul 2017 03:58:13 -0700 (PDT), Julio Di Egidio
> <ju...@diegidio.name> wrote:
>
> <snip>
> >No, C++ is certainly not a functional language.
>
> Then neither is ECMAScript : both languages have first-class function
> objects.

Ar you kidding?? No, C++ does not have functions as first-class.

Julio

[Thomas 'PointedEars' Lahn]

Ben Bacarisse wrote:

> […] That's all part of the late binding that some people consider so
> important.
>
> […] in a message passing language the message can fail if the

> object does not implement that particular message. In your examples,
> the message sending (which is just a function call) can't fail for that
> reason.
>
> To my mind, message passing would look rather more like:
>
> var msg = ["foo", 42, 23];
> o.process_message(msg);
>
> This would succeed or fail depending on whether o's prototype chain
> included a foo method at that time.

Calling a method on an object referred to by “o” – which in OOP/UML terms is
equivalent to sending a message to an object where the call’s arguments are
the message contents – *does* fail if that object does not have, and no
object in its prototype chain has, a method of that name *at runtime*.
*That* *is* late binding.

try
{
o.foo(42, 23);
}
catch (e)
{
/* TypeError: o.foo is not a function */
}

ISTM you are confusing messages sent to objects with those appended to a
message queue (which does not need to pertain to objects). Maybe because
you are accustomed to programming languages or software systems where
object-orientation is implemented in that way.

[John G Harris]

On Tue, 25 Jul 2017 05:59:49 -0700 (PDT), Julio Di Egidio

<ju...@diegidio.name> wrote:

>On Tuesday, July 25, 2017 at 10:42:57 AM UTC+2, John G Harris wrote:
>> On Mon, 24 Jul 2017 03:58:13 -0700 (PDT), Julio Di Egidio
>> <ju...@diegidio.name> wrote:
>>
>> <snip>
>> >No, C++ is certainly not a functional language.
>>
>> Then neither is ECMAScript : both languages have first-class function
>> objects.
>
>Ar you kidding?? No, C++ does not have functions as first-class.

Are you kidding? Haven't you heard of operator() ?

If you have then give us a well reasoned argument as to why this
doesn't imply first-class functions. Or why ECMAScript function
objects are somehow different.

John

[Ben Bacarisse]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:

> Ben Bacarisse wrote:
>
>> […] That's all part of the late binding that some people consider so
>> important.
>>
>> […] in a message passing language the message can fail if the
>> object does not implement that particular message. In your examples,
>> the message sending (which is just a function call) can't fail for that
>> reason.
>>
>> To my mind, message passing would look rather more like:
>>
>> var msg = ["foo", 42, 23];
>> o.process_message(msg);
>>
>> This would succeed or fail depending on whether o's prototype chain
>> included a foo method at that time.
>
> Calling a method on an object referred to by “o” – which in OOP/UML terms is
> equivalent to sending a message to an object where the call’s arguments are
> the message contents – *does* fail if that object does not have, and no
> object in its prototype chain has, a method of that name *at runtime*.
> *That* *is* late binding.

Yes, I know. Your example could not fail because it gave the object the
target method. I am sure that ECMAScript can something very like
Smalltalk's message passing, but the example was not close enough in my
opinion.

> try
> {
> o.foo(42, 23);
> }
> catch (e)
> {
> /* TypeError: o.foo is not a function */
> }
>
> ISTM you are confusing messages sent to objects with those appended to a
> message queue (which does not need to pertain to objects). Maybe because
> you are accustomed to programming languages or software systems where
> object-orientation is implemented in that way.

No.

--
Ben.

[Thomas 'PointedEars' Lahn]

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Ben Bacarisse wrote:
>>> To my mind, message passing would look rather more like:
>>>
>>> var msg = ["foo", 42, 23];
>>> o.process_message(msg);
>>>
>>> This would succeed or fail depending on whether o's prototype chain
>>> included a foo method at that time.
>>
>> Calling a method on an object referred to by “o” – which in OOP/UML terms
>> is equivalent to sending a message to an object where the call’s
>> arguments are the message contents – *does* fail if that object does not
>> have, and no object in its prototype chain has, a method of that name *at
>> runtime*. *That* *is* late binding.
>
> Yes, I know. Your example could not fail because it gave the object the
> target method.

No, the assignment

o.foo = f;

could have been silently discarded or modified because of a previous

Object.defineProperty(Object.prototype, "foo", {
"set": function () {
// …
}
});

> I am sure that ECMAScript can something very like Smalltalk's message
> passing, but the example was not close enough in my opinion.

I do not know Smalltalk well enough to confirm or deny this.