ask not what your object can do for you (was: Reflection and quotation)
Fri, 25 Aug 2000 13:42:43 -0700
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.
> 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
> >> its successor is.
> >I do.
> Your design is bad, then.
Please, are you deliberately trying to start a flame
> >> You do not ask rocks about the sand they will
> >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
> >> The former can be reduced to requesting the
> >> successor of a number from the behavior. That
> >> 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
> >> 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
> 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
> > 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
> >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,
> 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
I hope this helps,
This mail sent through Sinclair's WebMail