6 ms·

I am amazed that there would still be discussions about what OOP is or is not. The only agreement seems to be around "polymorphing" -- the ability to define a

I am amazed that there would still be discussions about what OOP is or is not. The only agreement seems to be around "polymorphing" -- the ability to define a behaviour that works consistently over many "things" that share some similarities. Good. But the root of evil comes back to very initial definition of what an object is: An "object" is something very concrete, it is not a mere "thing", it has: - an identity - a state - a behaviour Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values". However, the way a string is implemented is probably an object at some level (this is not true of a number, CPUs can deal with them directly). But this is an implementation detail. Unfortunately the essential difference between what is a Value and what is an Object is poorly promoted/teached. But this is improving thanks to functional languages. In a perfect world there would be "things", that are either "values" or "objects". In the imperfect world of us we have "objects", that are more or less mutable.

shadowfox 16y ago
> An "object" is something very concrete, it is not a mere "thing", it has: - an identity - a state - a behaviour. Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values". This seems to be strongly debated (still). Languages like Ruby (and Smalltalk) treat numbers as objects. You can argue that numbers are really objects with immutable state for example. This is not to say that I disagree with what you are saying. But the topic itself is still debated (as is a lot of stuff about the theory and basics of object systems)
- silentbicycle 16y ago
  Indeed. The meaning of "object" has always been pretty fuzzy in CS. When you compile C code, you get .o ("object") files. It's like "thingamajig".
  - jhrobert 16y ago
    That's because the source is the plan to build a table, whereas the .o file is the table itself. Tables are objects, plans to build tables are ideas.
    - silentbicycle 16y ago
      Sure, but the connection between that and "object" in the OOP sense is tenuous. For all it matters, the .o file could contain "chunks".
- jhrobert 16y ago
  OK. Let's get back to some basic vocabulary: What is a table. For sure, it is thing. And for sure it is an object too. What is "the plan to build a table" For sure it is something, hence it is a thing. But is it an object? Well, if the plan is printed on a piece of paper, then for sure it is an object. OTOH, if the plan for the table is in the head of some designer, then it is not an object, it's... an idea. So basically, you have two planes (at least), the "physical plane", where object lie, very tangible, very concreate, and the "idea plane" where ideas lie, very abstract. So, is 9 an object or and idea? In CS, things that lie in the "idea plan" are called "values". That's probably because we don't hold it (yet) that computers can have ideas ;) See also http://virteal.com/ObjectVersusValue http://virteal.com/ObjectVersusValue
joubert 16y ago
In most OOP scenarios one would model an application domain concept as a class, but then you get bogged down in implementing all sorts of minutiae that really have nothing to do in describing the model (e.g. getters/setters, initialization, etc.) Clojure, for one, encourages the distinction between data structures that represent the programming domain, and data structures that represent the application domain. There's defrecord, which goes a little further than record structures in other languages, in that it also gives the benefit of type-driven polymorphism.
- silentbicycle 16y ago
  Classes aren't necessary* for OO. Inheritance isn't necessary, either (and probably causes as many problems as it fixes). Late-binding via message-passing pretty much covers it, IMHO. Structure code as a group of autonomous actors communicating by passing messages according to agreed-upon protocols, and each (polymorphically) chooses how to react to them. Erlang implements that model with unusual clarity, IMHO. * Neither are prototypes.
contextfree 16y ago
Personally I think of object-oriented programming as meaning procedural data abstraction - in OOP, a data abstraction (object) is the operations that can be performed on it. This is in contrast to e.g. ML/Haskell algebraic types where a type is the set of values it can take. An object-oriented language is then a language designed to support this style of data abstraction, just as a (pure or impure) functional-oriented language is a language designed to support (where "support" is a superset of "enforce") a style of programming based on composition of pure functions. I am influenced by this paper -> http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOP... (warning: PDF), which expresses more carefully and precisely what I in the above paragraph expressed sloppily.
swannodette 16y ago
There doesn't need to be a distinction between Objects and Values: Object -> Object' -> Object'' -> Object''' -> ... The real problem with some popular OO languages is the conflation of state and identity. There are OO languages that avoid this "Worse Is Better" design. Haskell and Clojure come to mind.
- chc 16y ago
  Haskell is not an OO language at all.

shadowfox 16y ago

> An "object" is something very concrete, it is not a mere "thing", it has: - an identity - a state - a behaviour. Is a "hello" an object? No, no more than 9 or any number is an object, because these beasts are "values". This seems to be strongly debated (still). Languages like Ruby (and Smalltalk) treat numbers as objects. You can argue that numbers are really objects with immutable state for example. This is not to say that I disagree with what you are saying. But the topic itself is still debated (as is a lot of stuff about the theory and basics of object systems)

silentbicycle 16y ago
Indeed. The meaning of "object" has always been pretty fuzzy in CS. When you compile C code, you get .o ("object") files. It's like "thingamajig".
- jhrobert 16y ago
  That's because the source is the plan to build a table, whereas the .o file is the table itself. Tables are objects, plans to build tables are ideas.
  - silentbicycle 16y ago
    Sure, but the connection between that and "object" in the OOP sense is tenuous. For all it matters, the .o file could contain "chunks".
jhrobert 16y ago
OK. Let's get back to some basic vocabulary: What is a table. For sure, it is thing. And for sure it is an object too. What is "the plan to build a table" For sure it is something, hence it is a thing. But is it an object? Well, if the plan is printed on a piece of paper, then for sure it is an object. OTOH, if the plan for the table is in the head of some designer, then it is not an object, it's... an idea. So basically, you have two planes (at least), the "physical plane", where object lie, very tangible, very concreate, and the "idea plane" where ideas lie, very abstract. So, is 9 an object or and idea? In CS, things that lie in the "idea plan" are called "values". That's probably because we don't hold it (yet) that computers can have ideas ;) See also http://virteal.com/ObjectVersusValue http://virteal.com/ObjectVersusValue

joubert 16y ago

In most OOP scenarios one would model an application domain concept as a class, but then you get bogged down in implementing all sorts of minutiae that really have nothing to do in describing the model (e.g. getters/setters, initialization, etc.) Clojure, for one, encourages the distinction between data structures that represent the programming domain, and data structures that represent the application domain. There's defrecord, which goes a little further than record structures in other languages, in that it also gives the benefit of type-driven polymorphism.

silentbicycle 16y ago
Classes aren't necessary* for OO. Inheritance isn't necessary, either (and probably causes as many problems as it fixes). Late-binding via message-passing pretty much covers it, IMHO. Structure code as a group of autonomous actors communicating by passing messages according to agreed-upon protocols, and each (polymorphically) chooses how to react to them. Erlang implements that model with unusual clarity, IMHO. * Neither are prototypes.

contextfree 16y ago

Personally I think of object-oriented programming as meaning procedural data abstraction - in OOP, a data abstraction (object) is the operations that can be performed on it. This is in contrast to e.g. ML/Haskell algebraic types where a type is the set of values it can take. An object-oriented language is then a language designed to support this style of data abstraction, just as a (pure or impure) functional-oriented language is a language designed to support (where "support" is a superset of "enforce") a style of programming based on composition of pure functions. I am influenced by this paper -> http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOP... (warning: PDF), which expresses more carefully and precisely what I in the above paragraph expressed sloppily.

swannodette 16y ago

There doesn't need to be a distinction between Objects and Values: Object -> Object' -> Object'' -> Object''' -> ... The real problem with some popular OO languages is the conflation of state and identity. There are OO languages that avoid this "Worse Is Better" design. Haskell and Clojure come to mind.

chc 16y ago
Haskell is not an OO language at all.