ask not what your object can do for you
Fri, 25 Aug 2000 15:08:47 -0700
An excellent message; I understand your point far better now. Thanks.
From: Jecel Assumpcao Jr [mailto:firstname.lastname@example.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)
>> _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.