> The advantage of OO has always been its accessible constructs and abstractions that mirror how we talk about things linguistically.
I don't think there's much of a connection to natural language. OO is about commanding objects through messages; if we must make a connection to language, it would be equivalent to the imperative tense.
> Heck, even Clojure has its own object systems; they just often call them entities rather than objects
> I don't think there's much of a connection to natural language. OO is about commanding objects through messages; if we must make a connection to language, it would be equivalent to the imperative tense.
The community didn't scream out and say "but that language doesn't have messages, it can't be object oriented!" Of course, Alan Kay wasn't at ECOOP that year, but I did get an argument from Ralph Johnson that what I did was just Smalltalk :p.
> Which object systems would these be?
Clojure's (Rich Hickey's?) ideas about OO are surprisingly close to my own:
> OO is, among other things, an attempt to provide tools for modeling identity and state in programs (as well as associating behavior with state, and hierarchical classification, both ignored here). OO typically unifies identity and state, i.e. an object (identity) is a pointer to the memory that contains the value of its state.
The important thing about objects is their identity; they have names like Fred or Bob; they aren't anonymous values that can only be identified by their structure 42 or (2, 3).
> There is no way to observe a stable state (even to copy it) without blocking others from changing it.
He is not against objects, just how they are realized in imperative languages.
> OO doesn't have to be this way, but, usually, it is (Java/C++/Python/Ruby etc).
Yep. So he solves the problem in a smart way:
> In coming to Clojure from an OO language, you can use one of its persistent collections, e.g. maps, instead of objects. Use values as much as possible. And for those cases where your objects are truly modeling identities (far fewer cases than you might realize until you start thinking about it this way), you can use a Ref or Agent...
I will disagree, as soon as you have a collection with a key that is a GUID (or a name like Fred or Bob), you've just invented an object, whether its properties are embedded in the object or not.
Clojure just has its own ways of doing OO programming. If you hate OO, then you might simply claim "it is not OO", but this definitely is not pure functional programming that lacks identity at all (and pure Haskell solutions really do avoid all of this, Haskell is very non-OO in ways that pragmatic LISPs are not).
Note that there are other ways of fixing this problem, one can manage time so that object properties are always observed safely; this is the approach I'm currently taking with my own research:
If you are contrasting objects to pure values, that is really the main distinction: objects have names at design time, compile time, and run-time, values do not. I don't think it is unusually broad (at least it is not considered a radical position in the academic OOP community). Everything else: encapsulation, methods attached to data, subsumption, nominal subtyping, require that an object has its own identity and further support its "objectness."
Even if you didn't have these features in your language, they are fairly straightforward to construct in an ad hoc way as long as you have identity (that includes aliasing, obviously). Some kind of object system is often invented while building C programs of non-trivial size.
If the key isn't unique, then multiple objects could share the same state...they would be the same object!
I'm not sure what you mean by a "name". Do you mean the same thing as Hickey's definition of "identity", i.e. "a stable logical entity associated with a series of different values over time"?
Yes. To identify something whose fields change over time, it needs a name (even if that name is just a GUID or address). Well without fields, you don't need names, but this isn't a very interesting case (it is hard to scale up programs with just what are essentially global variables!).
Values are anonymous in contrast: you can't really tell the difference between this 42 and that 42.
> In computer science, an object is a location in memory having a value and possibly referenced by an identifier.
Not useful huh?
I would say, if the memory location is heap allocated and has mutable fields, then it is probably acting like an object (it could also be a value, it depends if its identity is important or not).
Wikipedia appears to distinguish between "object-based" languages and "object-orientated" languages. On the subject of object orientated languages, it says:
> An object has state (data) and behavior (code).
Which is the definition I'm most familiar with. I wouldn't class a Clojure reference as an "object", as it has state but no inherent behavior.
> I would say, if the memory location is heap allocated and has mutable fields, then it is probably acting like an object
So a reference to an immutable map wouldn't count as an object for you, because there are no mutable fields?
The reference to the immutable map doesn't count (a immutable map is just a value), but keys into the map can form objects (in that they represent "object" properties). Actually, that is how you get objects without first class mutability (identities must still be generated, of course, which is the same thing).
Ya, the wiki article makes a distinction between programming and designing with objects, and object-oriented programming. It really. All my arguments are about designing and programming with objects vs. designing and programming with values, call it "programming with objects" if you must.
I don't think there's much of a connection to natural language. OO is about commanding objects through messages; if we must make a connection to language, it would be equivalent to the imperative tense.
> Heck, even Clojure has its own object systems; they just often call them entities rather than objects
Which object systems would these be?