

A Proposal for Simplified Definitions of “Object” and “Object Oriented” (2012) - abecedarius
http://wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html

======
dllthomas
_" An object is a first-class, dynamically dispatched behavior. A behavior is
a collection of named operations that can be invoked by clients where the
operations may share additional hidden details. Dynamic dispatch means that
different objects can implement the same operation name(s) in different ways,
so the specific operation to be invoked must come from the object identified
in the client's request. First class means that objects have the same
capabilities as other kinds of values, including being passed to operations or
returned as the result of an operation.

A language or system is object oriented if it supports the dynamic creation
and use of objects. Support means that objects are easy to define and use. It
is possible to encode objects in C or Haskell, but an encoding is not
support."_

I'm perfectly happy to not call Haskell "object oriented", but I fail to see
how the "record of closures" pattern fails to meet all of his criteria
_including_ ease of creation and use.

Edited to add: To be clear, I fully agree with him that typeclasses have
nothing to do with OO in Haskell, by his definition of OO.

~~~
gamegoblin
I'm reminded of "Closures and Objects are equivalent"
([http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent](http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent))

That being said, you can easily create a data type in Haskell that contains a
bunch of "methods" that live in the IO monad and mutate other bits of data the
object contains that also live in the IO monad, but it's a bit of a forced
paradigm.

~~~
dllthomas
_' I'm reminded of "Closures and Objects are equivalent"'_

Sure, though to be clear I'm not taking any position on that question above. I
just think that the pattern solidly fulfills all of the criteria he gave, and
it's not a terrifically obscure one.

 _' That being said, you can easily create a data type in Haskell that
contains a bunch of "methods" that live in the IO monad and mutate other bits
of data the object contains that also live in the IO monad, but it's a bit of
a forced paradigm.'_

I think what you're getting at here is that persistent identity and mutable
state are necessary parts of IO? It's clear that they're often assumed to be;
I've encountered the question before and I lean weakly "no", although not with
confidence. More importantly, they are explicitly _disclaimed_ as being an
inherent part of IO as defined in the article, so were not what I was speaking
to. I agree that an IO-backed message passing object framework 1) could be
built in Haskell and 2) would not be a natural fit.

~~~
dllthomas
... necessary parts of _O_ O.

------
dgreensp
I love it. Just a few nits -- wording that struck me funny -- all of which are
eventually addressed within the article:

1\. "An object is a behavior." This is a meaningless or misleading use of "is"
to me. I prefer "an X with behavior" or "a thing distinguished by (considered
for?) its behavior."

2\. The statement that not all Java classes define objects (for example, ones
with lots of fields), and that saying this is in keeping with common ways of
speaking. No, a programmer would call any object in Java an "object." I get
that the point is to say that a struct does not make an object, but the point
seemed overstated in that case.

3\. Objects must have "recognizable identity," but you don't have to be able
to compare the identity of two objects (really it should say two object values
or two references). "Recognizing" is being used in a very abstract way here,
to avoid invoking state to explain the potential difference between objects. I
think it's a little too subtle, even if the point is elaborated on later. If
you have any other way to articulate what gives objects identity even if you
can't detect it directly, I think it would help. To most readers, I think
"recognizing" identity would mean being able to check whether you have a
reference to a given object or not, which means being able to compare
references. Are there OO languages where you can't? I'm not objecting to
downplaying identity.

~~~
abecedarius
Re 2: I believe he had in mind a class used only to define some static
methods.

The original OO language, that is the lambda calculus, had no reference
comparison -- All You Can Do Is Send A Message is the slogan in general.
[http://www.erights.org/elib/equality/grant-
matcher/history.h...](http://www.erights.org/elib/equality/grant-
matcher/history.html) lists some less familiar ones.

Given mutability, identity determines how a message to one object reference
affects what happens when you invoke another one. If you go up from the above
URL you'll see a bunch more discussion.

------
programminggeek
It is unfortunate that we still are worried about objects and aren't so
worried about messages. Most devs don't think about or care much about
messages at all.

