On TheValueOfDomainModels CostinCozianu wrote:

I also don't believe in ''object= data + behavior. PERIOD.'' approach. Functions and data are really separate and distinct entities, I arrived to the conclusion that we bundle them together just as a psychological convenience, it is much more convenient for us to reason of them as a bundle.

As a matter of fact, it is proven in StructureAndInterpretationOfComputerPrograms, that starting with only primitive data types and using functions you can build no-matter how complex data structures.

The other thing that is bothering is that when somebody says ''x.method()'' is really different than ''method(x)'' at most he refers to syntactic convenience. More, this syntactic convenience comes back to haunt us, as we have to do some really nice hacks to achieve MultipleDispatch.

-- CostinCozianu

----

I think that if we see functions and data as separate it is because we have chosen to see them that way. They are abstractions that we use to reason about our work, just as objects are.

The nice thing about the ''x.method ()'' syntax is that it identifies a ''receiver'', a target for a ''message''. I haven't seen anyone take this tack, but ''(a,b,c).message()'' seems like a reasonable syntax.

-- MichaelFeathers

''Actually, I'm reasonably sure that that's what CLOS MultiMethods are.'' -- KyleBrown

----

That's the approach I identified in StopUsingMetaphors. What makes you think that you can send a ''message'' to a bank account, and what makes you think that a bank account is ''really'' a receiver of messages? This is just psychological, since it can be mathematically proven that a ''method(x)'' approach that separates data from functions, and can work with Abstract Data Types, is ''easily'' isomorphic with a Smalltalk-like system that sends messages to objects. While the first has a lot more expressive power, because it can do MultipleDispatch very easily.

An eloquent example is Ada 95 but unfortunately very few people recognize Ada as an OO language, sure Ada doesn't support the (a,b,c).message(), but with traditional function(a,b,c). By having an (a,b,c).message() we would rather suggest an operation (message dispatching) on sets of objects - another area where OO has been traditionally weak, rather than a MultipleDispatch which is very different, and in many cases multiple dispatch is what we need.

Furthermore, I identified that the ''objects and messages'' approach historically derived from Simula, was justified by the fact that Simula was initially thought of as a language to address simulation and operational research. These are domains where this approach is perfectly suited because the complexity of the problems being addressed prevents a higher level of abstraction. But the same is not justified for other classes of problems that are amenable to higher levels of abstraction and more formalism. -- CostinCozianu

----

[Move me?]
Still off-topic, but '''function(a)''' is equivalent to '''contextObject.function(a)'''. Whenever the function operates on more objects than '''a''' itself, this form is the correct one (by OO principles). This resolves a lot of the ambiguity of objects acting as operators. Generally, OO theory is weak on peer relationships due (IMO) to the (over)emphasis on encapsulation. Messaging is a partial response, but has granularity problems as well as creating profitable infrastructure issues.

Thus Double.divide(Double) is pretty silly. Math.divide(Double, Double) makes much more sense. The former is not scalable (or normalised ;)), whereas the latter is.

This is a rich topic in programming theory, though rather unfashionable.

-- RichardHenderson

The contextObject.function(a) is an interesting approach, and is even better when the contextObject is implicit (you can pick it from the thread of execution, for example). On the other hand, even contextObject.function(a) is better to be defined as function(a,contextObject), if I understood it correctly, because it doesn't force any unnecessary burden on the contextObject. Functions are not all evils. Functions that have no contextual dependence are even better, though they are not always possible.

But as a matter of principles, OO or not-OO, functional or structured programming, or even constraint based programming, it is always good when the environemnt (programming language, libraries, runtime, etc.) allows you to use more than one paradigm, so you can pick the best approach for each problem. Sending messages to objects is a good thing in many cases, while in other cases is not necessarily the best thing. -- CostinCozianu

''Yes. My point is that they are all equivalent syntaxes. The use of an explicit rather than global scope (as in Math.divide() as opposed to simply divide() ) reflects the reality of the situation, which I consider preferable. -- RichardHenderson''
-------
See Also: DataAndCodeAreTheSameThing