ask not what your object can do for you (was: Reflection and quotation)

[Jecel Assumpcao Jr]

On Thu, 24 Aug 2000, Kyle Lahnakoski wrote:
> Maybe this needs more explanation.  You do not ask 4 what its successor
> is. 

I do.

> You do not ask rocks about the sand they will become. 

I do.

> You analyze
> the behavior of the integers, and produce the answer yourself, or you
> ask God for the successor. 

Good - I thought you were trying to tell me that integers have no
behavior ;-)

> The former can be reduced to requesting the
> successor of a number from the behavior.  That means the behavior is an
> object, and that object should be the one handling the requests.  It
> also handles such operations as addition and multiplication.  I call
> this object the Integer_Class.  Notice the clean implications:  add two
> numbers together is a symmetrical operation Integer_Class.add(a=4,
> b=3).  

This is an alternative and valid design, but it isn't the only one
possible nor even the best one. It is how things end up being done at
the most primitive level, I'll grant you that:

    hardwareALU add: 3 To: 4

> The poor method of adding integers required messages to be sent to the
> numbers. 

I don't agree that it is "poor".

> Therefore 4 + 3 was logically different from 3 + 4 in terms of
> message passing.  This is bad design because you deliberately introduce
> the anomaly of asymmetry for an operation that should logically be
> symmetrical.

Use a language with multiple dispatching (like Cecil) if you are really
worried about that. I agree it is a problem, but don't feel it is
serious enough to throw object orientation away.

How about this other example - I want the object 4 to return true
when sent the message "even" but the object 3 to return false to the
same message. Sure, you could add this method to your Integer_Class:

        return ( ( this % 2 ) == 0 )

I don't doubt that you will feel this is the best way to do it. In
fact, you might feel this is the only right way to do it. But I don't
think so - to me integers just happen to be particularly uniform
objects that fit very well in your viewpoint, but aren't so typical of
objects in general.

-- Jecel