ask not what your object can do for you (was: Reflection and
Fri, 25 Aug 2000 11:25:42 -0700
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:email@example.com]
>On Thu, 24 Aug 2000, Kyle Lahnakoski wrote:
>> Maybe this needs more explanation. You do not ask 4 what
>> its successor is.
Your design is bad, then.
>> You do not ask rocks about the sand they will become.
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
_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,
>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
(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
>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.