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 2 of 2 — ← Prev page 1 [2]

#33666

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.

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

#33668

Thomas 'PointedEars' Lahn <PointedEars@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.

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

#33672

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@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.

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

#33639

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.4vTCxPXJkl@PointedEars.de>
    <news:3306468.kQq0lBPeGt@PointedEars.de>
    <news:3160292.R56niFO833@PointedEars.de>
-- 
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]

#33641

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

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

#33643

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

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

#33645

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

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

#33661

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

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

#33665

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

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

#33667

On Tue, 25 Jul 2017 05:59:49 -0700 (PDT), Julio Di Egidio
<julio@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
>> <julio@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

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

#33626

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"?

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.

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

#33627

On Sunday, July 23, 2017 at 10:43:06 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
> 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"?
> 
> 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.

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

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

#33644

On Sun, 23 Jul 2017 22:42:55 +0200, Thomas 'PointedEars' Lahn
<PointedEars@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

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

#33649

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.

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

#33653

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> 

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

#33654

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

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

#33663

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

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

#33642

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

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

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

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

#33652

John G Harris wrote:

> On Sun, 23 Jul 2017 18:12:10 +0200, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>>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.
> 
> 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.)

-- 
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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web