Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #33602 > unrolled thread

Not understanding OOP stuff

Back to article view | Back to comp.lang.javascript

Contents

  Not understanding OOP stuff bit-naughty@hotmail.com - 2017-07-21 09:11 -0700
    Re: Not understanding OOP stuff JJ <jj4public@vfemail.net> - 2017-07-22 19:36 +0700
    Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-23 18:12 +0200
      Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 09:19 -0700
        Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-23 20:10 +0100
          Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 12:42 -0700
            Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-23 22:03 +0100
              Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 14:18 -0700
                Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-24 03:22 +0100
                  Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 21:44 -0700
              Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-24 03:49 +0100
                Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 21:50 -0700
                  Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-24 19:50 +0100
                    Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-24 12:00 -0700
                      Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-25 09:29 +0100
                        Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-25 05:58 -0700
                Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-24 11:04 +0200
                  Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-25 00:09 +0100
                    Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-25 09:20 +0100
                      Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-25 11:31 +0100
                    Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-25 17:02 +0200
                      Re: Not understanding OOP stuff Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-07-25 23:47 +0100
                        Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-27 15:15 +0200
              Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-24 10:33 +0200
                Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-24 02:13 -0700
            Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-24 11:15 +0100
              Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-24 03:58 -0700
                Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-25 09:42 +0100
                  Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-25 05:59 -0700
                    Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-25 18:32 +0100
          Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-23 22:42 +0200
            Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-23 13:55 -0700
            Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-24 11:18 +0100
              Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-24 15:19 +0200
        Re: Not understanding OOP stuff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-07-24 10:20 -0700
          Re: Not understanding OOP stuff Julio Di Egidio <julio@diegidio.name> - 2017-07-24 11:46 -0700
            Re: Not understanding OOP stuff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-07-25 05:37 -0700
      Re: Not understanding OOP stuff John G Harris <niam@jghnorth.org.uk.invalid> - 2017-07-24 11:04 +0100
        Re: Not understanding OOP stuff Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-07-24 16:04 +0200

Page 1 of 2  [1] 2  Next page →

#33602 — Not understanding OOP stuff

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.

[toc] | [next] | [standalone]

#33608

On Fri, 21 Jul 2017 09:11:09 -0700 (PDT), bit-naughty@hotmail.com wrote:
> 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.

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>

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

#33619

Stefan Ram wrote:

> bit-naughty@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.

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

#33620

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

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

#33624

Julio Di Egidio <julio@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.)

-- 
Ben.

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

#33625

On Sunday, July 23, 2017 at 9:10:58 PM UTC+2, Ben Bacarisse wrote:
> Julio Di Egidio <julio@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.

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

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

#33628

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

> On Sunday, July 23, 2017 at 9:10:58 PM UTC+2, Ben Bacarisse wrote:
>> Julio Di Egidio <julio@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.

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

#33629

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

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

#33631

Julio Di Egidio <julio@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.

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

#33635

On Monday, July 24, 2017 at 4:22:24 AM UTC+2, Ben Bacarisse wrote:
> Julio Di Egidio <julio@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.

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

*Plonk*

Julio

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

#33632

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

> Ben Bacarisse <ben.usenet@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.

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

#33636

On Monday, July 24, 2017 at 4:49:54 AM UTC+2, Ben Bacarisse wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > Ben Bacarisse <ben.usenet@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.

<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

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

#33655

On Sun, 23 Jul 2017 21:50:06 -0700 (PDT), Julio Di Egidio
<julio@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

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

#33656

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
> <julio@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

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

#33660

On Mon, 24 Jul 2017 12:00:06 -0700 (PDT), Julio Di Egidio
<julio@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
>> <julio@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

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

#33664

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

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

#33640

Ben Bacarisse wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> Ben Bacarisse <ben.usenet@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/>

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

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

#33658

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

> Ben Bacarisse wrote:
>
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> Ben Bacarisse <ben.usenet@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]);

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

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

#33659

On Tue, 25 Jul 2017 00:09:20 +0100, Ben Bacarisse
<ben.usenet@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

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

#33662

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

> On Tue, 25 Jul 2017 00:09:20 +0100, Ben Bacarisse
> <ben.usenet@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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web