ask not what your object can do for you

[Jecel Assumpcao Jr]

On Fri, 25 Aug 2000, btanksley@hifn.com wrote:
> Your design is bad, then.

Thank you. I respect your opinion and suppose that it is based not only
on this little comment I made but also on the extensive example of my
design style that I sent earlier to the list.

I have previously said that I don't believe in universal solutions.
Before the Tunes list was started, Faré and I talked about merging our
projects. But I didn't think he, nor the majority of the list, would
like what I was going to do. So I kept Merlin separate. Different
solutions to different problems for different people.
       
> 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

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

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.
       
> Aspect oriented programming produces a better model of some things than
> object oriented programming. 

True. And Functional Programming does better for a number of things.
And there are problems for which I would like nothing better than Logic
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).

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

> 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?
  
> Why would you deliberately use an abstraction which matches neither the
> abstract nor the concrete behavior?

It matches my model of how things work.

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

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

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

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

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

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

-- Jecel