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

[btanksley@hifn.com]

From: Brian Rice [mailto:water@mail.tscnet.net]
>Quoting btanksley@hifn.com:
>> 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.

>Please, are you deliberately trying to start a flame 
>war?

I deeply apologise for any unclarity in that statement, especially that
caused by my terseness.  No, I certainly did NOT mean to start a flamewar.
What I meant to imply was that the design he's applied to his mental model
of the universe is not accurate.  Therefore, his programs are constrained to
act in only one way, a way which is not always appropriate.

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

>I think you're confusing the issue. The rock simply is 
>a conduit for obtaining the information. You don't ask 
>an object because it "knows" or it is smart enough 
>to "know", you ask because it can delegate the question 
>on its own to the knowing collection of objects.

But the rock is NOT a container to its surrounding area; that's not
something it should be responsible for.

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

>Contradictory if you're taking Integers to refer to the 
>class of individual integers. Perhaps the desired term 
>is the _group_ or field or somesuch of the integers?

I meant exactly what I said, and I _am_ taking Integers to "refer to the
class of individual integers."  The class of Integers defines a successor to
4.  4 alone doesn't -- unless, of course, you're using a special notation in
which the text "4" always represents the integer_mod_2^32(4).  This is,
thankfully, common in programming languages.

Another common assumption in languages is that there's a single language
model for the behavior of 'numeric objects', where a numeric object is like
a number, except that it carries its type along with it for speed and
precision.  Therefore, you don't have to say integer.add(4,3) because the
'add' function (or rather, the application of the add function) uses that
extra information the numbers happen to be carrying with them.

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

>Pardon? I thought (and I've looked at AOP quite a bit, 
>including the conference papers) was that aspect-
>orientation sits *atop* other paradigms and uses each 
>when appropriate.

Kinda, but I'd say that AOP sits alongside other paradigms; I wouldn't say
that it *relies* on OO or anything else.  It certainly provides new ways of
expressing aspects, though.

Anyhow, my point was that AOP is a useful model for things, and it's not OO.

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

>This is absurd...

Eh?

>the problem here is that "5" and "7" 
>must be overloaded, and you have completely ignored 
>that in the code. Where does the binding for "5" 
>and "7" come from in your example? If it's a normal 
>programming language, than it's an absurdity 
>because "5" and "7" are statically bound by the 
>language definition. They can't possibly mean anything 
>other than integers (or reals in languages that munge 
>things even more).

No, they could mean almost anything.  However, I do understand what you're
saying (in a sense); it seems strange to talk to a group about its members,
when its members already know what group they belong to.  In a sense, it's a
reversal of object orientation to become class-oriented.

>This *does* point out problems in 
>languages (which I'm specifically working on in Slate 
>(yes, this is why I replied at all)), but it doesn't 
>suggest that the concept is broken. Rather, the way 
>that languages work is broken.

I hate to repeat myself, but "Eh?"

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

>Could you explain the necessary aspect? Is it merely 
>multiple dispatch or are you suggesting something else? 
>(I ask this for the benefit of Kyle and the list.)

I don't know what you mean by "the neccesary aspect."  However, I did
mention the addition of a new object -- the new object is the class to which
I'm sending the add message.

>The example was badly-formed.

Okay.  Well, that happens.

>Jecel (I submit) was 
>trying to point out the idea that the code there is 
>based on the static lexical support for the integers. 
>More generally, hardware-oriented computing.

I don't understand this at all.

-Billy