Re: [pldesign] A Proposal for Standard Definition of Object and Object-Oriented

[William Cook]

Crista,

I've realized that I'm actually *more* consistent with practice. In particular, according to current definitions, JavaScript is not OO, because it doesn't have classes and inheritance.

I'm using "module" in a very weak sense, to mean "bag of definitions, with possible hidden stuff"

Where does Andrew say polymorphism is not needed for OO?

W


On 7/13/12 3:56 AM, Crista Lopes wrote:

[Sorry, I don't know what the Google group is]

On 7/12/2012 6:54 AM, William Cook wrote:

So, I strongly disagree with the idea that "Polymorphic modules that can't be extended and repurposed are as useful as any other modules that came before". This is because it is exactly polymorphism that enables "the potential for re-appropriation of interfaces and implementations that really made objects important, more than the concept of object in isolation."

Can you clarify what you mean?

I mean you're stopping too short for the definition to reflect what people think as OOP, I think. Or you're placing the line in some strange place. I'm not questioning your definition (it's perfectly reasonable), I'm questioning (a) its usefulness in practice; and (2) ignoring practice, the criteria for drawing the line at polymorphism. If it's mainly for convincing some FP people that you think don't understand objects but that you think understand polymorphism, maybe that's fine. Maybe.

Inheritance is definitely not a property of objects, so I agree that it doesn't belong in a minimalistic definition of objects. Neither is polymorphism, as Andrew points out. So not sure why mention one but not the other(s).

Here's an alternative definition of objects, even more minimalistic, along your lines, but avoiding the words "module" and "polymorphism":

"Objects are bags of procedures".

(inspiration taken liberally from information retrieval, "documents"="bags of words")

Like in IR systems, the system manipulating these bags of procedures can do it in many different ways. It can literally place the procedures inside the bags, or it can place the procedures in bags called "classes" and have bags of references to procedures called "instances"; it can include state in those bags or not; it can allow the replacement of bags with other "compatible bags" from under the bag users; it can allow bags to pass bags to other bags as they invoke procedures elsewhere; etc. etc. Those are all features of the systems manipulating the bags, and not of the bags themselves.

--
William Cook
Associate Professor, Computer Science
University of Texas at Austin

[Crista Lopes]

On 7/13/2012 7:47 AM, William Cook wrote:

Crista,

I've realized that I'm actually *more* consistent with practice. In particular, according to current definitions, JavaScript is not OO, because it doesn't have classes and inheritance.

Indeed. Not sure if you're being subtle, but I thought that by your definition, inheritance is not required for OOP? If I understood your definition, then JS would be considered OO under it, whereas "current definitions" would say it isn't [without inheritance].

In any case, JS is a great example for illustrating what OOP means in practice. When people think of JavaScript to do OOP, they immediately go down the road of explaining how to do abstraction, information hiding, polymorphism, and, most importantly, inheritance (prototypes, etc). Here are some examples:

https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript
http://www.javascriptkit.com/javatutors/oopjs3.shtml
http://mckoss.com/jscript/object.htm
http://killdream.github.com/blog/2011/10/understanding-javascript-oop/
etc.

You will not find a single article out there placing JavaScript and OOP in the same page without mentioning how to do inheritance with prototypes.

I'm using "module" in a very weak sense, to mean "bag of definitions, with possible hidden stuff"

Then we're on the same page. I'd rather use "bag"; "module" is overloaded in this community.

Where does Andrew say polymorphism is not needed for OO?

He didn't say that. He pointed out that polymorphism is not a property of the objects in isolation. You said that too in the clarification text. But not in the definition; hence your definition of object makes an incursion into the system around them. I think that it's better to either stay completely away from the systems around objects [I like that as minimalist definitions go], or else include the mechanisms of the systems around objects that ppl have converged to when they think OOP -- inheritance, or at least some form of re-appropriation of procedures, would be a must there, along with first-class-ness and polymorphism.

[William Cook]

Yes, JavaScript *is* an OO language according to my definition. I'm sorry I was not clear.

About polymorphism, i've been playing with alternatives
  "an object is a first-class module that is invoked polymorphically"
Is that better? It is not quite so clean, but perhaps more accurate.

This discussion is very interesting and helpful. I suppose I could put in some kind of
requirement for "extensibility" or "open recursion".

  "an object is a first-class module that is invoked polymorphically, and whose definition is open to extension"

Basically we get "OO = polymorphism + open recursion"

Is that what you want?

W

On 7/13/12 10:28 AM, Crista Lopes wrote:

On 7/13/2012 7:47 AM, William Cook wrote:

Crista,

I've realized that I'm actually *more* consistent with practice. In particular, according to current definitions, JavaScript is not OO, because it doesn't have classes and inheritance.

Indeed. Not sure if you're being subtle, but I thought that by your definition, inheritance is not required for OOP? If I understood your definition, then JS would be considered OO under it, whereas "current definitions" would say it isn't.

In any case, JS is a great example for illustrating what OOP means in practice. When people think of JavaScript to do OOP, they immediately go down the road of explaining how to do abstraction, information hiding, polymorphism, and, most importantly, inheritance (prototypes, etc). Here are some examples:

https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript
http://www.javascriptkit.com/javatutors/oopjs3.shtml
http://mckoss.com/jscript/object.htm
http://killdream.github.com/blog/2011/10/understanding-javascript-oop/
etc.

You will not find a single article out there placing JavaScript and OOP in the same page without mentioning how to do inheritance with prototypes.

I'm using "module" in a very weak sense, to mean "bag of definitions, with possible hidden stuff"

Then we're on the same page. I'd rather use "bag"; "module" is overloaded in this community.

Where does Andrew say polymorphism is not needed for OO?

He didn't say that. He pointed out that polymorphism is not a property of the objects in isolation. You said that too in the clarification text. But not in the definition; hence your definition of object makes an incursion into the system around them. I think that it's better to either stay completely away from the systems around objects, or else include the mechanisms of the systems around objects that ppl have converged to when they think OOP -- inheritance, or at least some form of re-appropriation of procedures, would be a must there, along with first-class-ness and polymorphism.

W


On 7/13/12 3:56 AM, Crista Lopes wrote:

[Sorry, I don't know what the Google group is]

On 7/12/2012 6:54 AM, William Cook wrote:

So, I strongly disagree with the idea that "Polymorphic modules that can't be extended and repurposed are as useful as any other modules that came before". This is because it is exactly polymorphism that enables "the potential for re-appropriation of interfaces and implementations that really made objects important, more than the concept of object in isolation."

Can you clarify what you mean?

I mean you're stopping too short for the definition to reflect what people think as OOP, I think. Or you're placing the line in some strange place. I'm not questioning your definition (it's perfectly reasonable), I'm questioning (a) its usefulness in practice; and (2) ignoring practice, the criteria for drawing the line at polymorphism. If it's mainly for convincing some FP people that you think don't understand objects but that you think understand polymorphism, maybe that's fine. Maybe.

Inheritance is definitely not a property of objects, so I agree that it doesn't belong in a minimalistic definition of objects. Neither is polymorphism, as Andrew points out. So not sure why mention one but not the other(s).

Here's an alternative definition of objects, even more minimalistic, along your lines, but avoiding the words "module" and "polymorphism":

"Objects are bags of procedures".

(inspiration taken liberally from information retrieval, "documents"="bags of words")

Like in IR systems, the system manipulating these bags of procedures can do it in many different ways. It can literally place the procedures inside the bags, or it can place the procedures in bags called "classes" and have bags of references to procedures called "instances"; it can include state in those bags or not; it can allow the replacement of bags with other "compatible bags" from under the bag users; it can allow bags to pass bags to other bags as they invoke procedures elsewhere; etc. etc. Those are all features of the systems manipulating the bags, and not of the bags themselves.

--
William Cook
Associate Professor, Computer Science
University of Texas at Austin

[Crista Lopes]

On 7/13/2012 9:26 AM, William Cook wrote:
> Basically we get "OO = polymorphism + open recursion"
> Is that what you want?

If you go down the road of mentioning exo-object properties, yes, I
think that would make it a bit more consistent with practice.

But I'm also very ok with the extremely minimalistic definition of
object as a bag of procedures, period -- nothing said about how to use
these bags and what more constraints/features to add to them within a
system [language] of bags of procedures. If you think in FP terms, it's
a subtle conceptual change to go from 1 single procedure (or a
collection of unrelated procedures) to a collection of procedures that
are grouped together possibly sharing something... very subtle change.

[Kevlin Henney]

On 13 July 2012 17:16, Crista Lopes <lo...@ics.uci.edu> wrote:

 

Indeed. Not sure if you're being subtle, but I thought that by your definition, inheritance is not required for OOP? If I understood your definition, then JS would be considered OO under it, whereas "current definitions" would say it isn't [without inheritance].

In any case, JS is a great example for illustrating what OOP means in practice. When people think of JavaScript to do OOP, they immediately go down the road of explaining how to do abstraction, information hiding, polymorphism, and, most importantly, inheritance (prototypes, etc).

My talk, "It Is Possible to Do Object-Oriented Programming in Java", is all about defining OOP and includes a direct translation of an example from Lambda to JavaScript (late on in the talk, if you're interested). Here's the QCon London run of that talk:

http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java

Kevlin

--
________________________

  Kevlin Henney
  +44 7801 073 508
  http://curbralan.com
  http://kevlin.tel
________________________