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

[btanksley@hifn.com]

Sorry, I sent this message only to Jecel.  I meant to reply to the group.  I
hate the way this mailing list is configured.

From: Jecel Assumpcao Jr [mailto:jecel@tunes.org]
>On Thu, 24 Aug 2000, Kyle Lahnakoski wrote:
>> Maybe this needs more explanation.  You do not ask 4 what 
>> its successor is. 
>I do.

Your design is bad, then.

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

I would ask Geology about that.  The rocks might have a tiny bit of info
about that, but the surrounding conditions are FAR more important.  (Are the
rocks in a subduction zone?)

>> 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 ;-)

_Integers_ have behavior.  4 alone doesn't.

Aspect oriented programming produces a better model of some things than
object oriented programming.  Check it out (the best starting point I know
of is at http://www.aspectj.com, although some of the best papers on the
subject are not at that site).

>> 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

It's also how things are done at the _highest_ level,

theGroupToWhichTheseThingsBelong add: 5 to: 7
--> 1

(Ahah, the group was the integers modulo 11.)

Why would you deliberately use an abstraction which matches neither the
abstract nor the concrete behavior?

>> 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.

Squeak does that too -- get the MathDD goodie.

>I agree it is a problem, but don't feel it is
>serious enough to throw object orientation away.

We're NOT throwing OO away.  It's at WORST the addition of aspect
orientation, and at LEAST the addition of a new object to our model.  I find
it hard to believe that you're claiming that a design which doesn't match
yours isn't object oriented.

>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.

I see the example clearly, but I don't see how it supports your concept.
It's especially bad that your rebuttal is merely "You may feel this way, but
I don't think so."  It's also odd that your rebuttal appears to be a
rebuttal not of his idea, but rather of the EXAMPLE you yourself gave.  If
you didn't like that example, why did you give it?

BTW, I don't think "his way" is the only right way to do that.  It's merely
the best way.  Your way will also work.

>-- Jecel

-Billy