ask not what your object can do for you

[btanksley@hifn.com]

An excellent message; I understand your point far better now.  Thanks.

From: Jecel Assumpcao Jr [mailto:jecel@tunes.org]
>> 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?)

>   rock asSandIn: environment

A valid design.  Also interesting would be:

   [environment age] until [rock isSand]
   environment reduceToSand: rock
   geology getSandFormOf: rock
   geology getSandFormOf: rock in: environment

Pardon the pidgin Smalltalk ;-).

The last three are the 'functional' versions, of course.  Your version (and
my version which dispatches from 'environment') are also functional, and
have the advantage of requiring less typing; OTOH, they have some (obvious)
disadvantages.

>> _Integers_ have behavior.  4 alone doesn't.

>Right. And Screen has behavior, but a pixel doesn't. This is the well
>known "fly-weight objects" design pattern. I use it for the most
>commonly used numbers to get a better performance, but I don't use it
>for all numbers.

That's a good point of view -- I actually wasn't thinking of flyweights when
I said that.  I was thinking more of methematical models.

>Let's move to a simpler example: booleans. Here there are only two -
>true and false (until we get to fuzzy logic...). Should an imaginary
>_Booleans_ hold their behavior (most languages) or should the objects
>themselves have behavior (Self)? Both styles have advantages.

...good point.  Mathematical model or not, the important thing for us is how
well it works in practice.

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

>Thanks. It had been a long time since I had looked at the Xerox cite
>(see the links section of AspectJ).

Yup.  AspectJ is actually the same people (or at least the same group).  I
like some of the papers at the Xerox site better, though -- and I don't
quite trust AspectJ yet.

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

>I don't understand how this works: where is the information about the
>group to which the two numbers belong stored?

Looks like it's in the variable 'theGroupToWhichTheseThingsBelong'.

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

>It matches my model of how things work.

Add one phrase to that, and it's sufficient: "...and my model makes my code
easy enough to write and extend."

>> >Use a language with multiple dispatching (like Cecil) if 
>> >you are really worried about that.

>> Squeak does that too -- get the MathDD goodie.

>Well, double dispatching is an awkward simulation of multiple
>dispatching. When you find yourself using it, you have stumbled across
>a domain where objects are not the best model.

My fault -- I misread your sentance.  Yes, you're right (although MD doesn't
seem to me to rule out OO, it only rules out information hiding).  Hmm,
maybe I just have a bad definition of OO -- to me, a design is OO only if it
upholds object identity.

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

>Adding Aspects seems like stepping back from objects to me: to take
>what was a single bundle and spread it around in several places. On the
>other hand, what was spread around before has now been brought together
>but as aspects, not objects. Same thing with reflection - don't let the
>terms like "meta object" fool you. The system becomes less object
>oriented. And that is ok.

AOP doesn't _remove_ OO, though.  It's a completely different dimension.
Very OO code can have no AOP, and vice versa.

I don't understand reflection, and your statement about how it makes a
system less OO makes me believe that I understand it FAR less than I thought
I did.  I assumed that reflection referred to a system's ability to modify
itself, right?  What does that have to do with OO?

>> >["even" example]
>> 
>> I see the example clearly, but I don't see how it supports 
>> your concept.

>I could put an "even = true" slot in half of the integer objects and an
>"even = false" in the other half. That would work, as does sharing a
>single "even = (0==(self%2))" slot among all objects.

Oh, I see!  I didn't realise that you were implying that.  Now your example,
and your words after it, seem to fit in your post a LOT better.

>> It's especially bad that your rebuttal is merely "You may feel this
>> way, but I don't think so." 

>I was claiming it was a matter of taste, not absolute truth.

That's true to a certain extent.  I would say more that it's a matter of
extremes -- either extreme is VERY bad for some things and VERY good for
others.  The stuff in between has no perfect dividing line which applies to
all programmers, so THAT's a matter of taste.

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

>This isn't a competition that I am trying to win. It is a simple
>exchange of ideas. I like the example, even though it makes Kyle's
>position seem more reasonable than mine. It is my way of saying "I
>think  I understand where you are coming from".

I see now!  :-)

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

>I agree with that, but for me "best = best most of the time", not
>always and in every possible future application.

You're absolutely right.

>-- Jecel

-Billy