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

[Brian Rice]

Here's my attempt to arbitrate between Jecel and others 
when I barely have enough time for email at all. This 
kind of mis-understanding is exactly the wrong thing to 
start bashing each other about.

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

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

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

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

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

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

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

The example was badly-formed. 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.

> >-- Jecel
> 
> -Billy

I hope this helps,
~


=========================================
This mail sent through Sinclair's WebMail
      http://mail.sinclair.net