ask not what your object can do for you

[Kyle Lahnakoski]

If I get this right, Jecel says that adding attributes, to 4 in our
example, is done for optimization purposes.  This optimization can be
either in the form of reduced execution time or reduced syntactic
complexity.  Those are certainly valid reasons, as long as we remember
why we are doing this design change.

I would suspect Tunes should eventually solve both these issues.  It
should also  keep the "correct" representation available for inspection
by beginners who may not know the attributes exist for optimization
only.  Increased execution speed should come from the dynamic reflective
compilers.  Shorter syntactic sequences should be handled as syntactic
shortcuts in the language.

I come from database theory, for this reason I see this issue of
attribute placement as an OO form of normalization.

http://www.bus.orst.edu/faculty/brownc/LECTURES/DB_TUTOR/Normal_Forms.htm

Here it is assumed the normal form is the logically right representation
for data.  It assumes that attribute duplication is a bad thing: a
purely normalized database can handle single attribute changes and still
be consistent.  Of course, put to practice, results in slow database
access.  

I suggest an axiom be developed that covers this concept of attribute
placement.  Here is my first suggestion:

	Consider a method of an object.  If, for each set of parameter
	values, the method returns the same value for the lifetime of
	the object then we call this a predictable method.  If the
	method for every object in a class is predictable, but still
	depends on the identity of the object, then that method should
	exist, in one form or other, in the class.  

Applying this axiom: the successor of 4 will always be the same,
therefore successor() should belong to the Integer_Class.  Similarly for
add().

Verifying if add() belongs to the Integer_Class forces us to notice that
add(int x, int y) is purely functional, and our axiom suggests keeping
the method where it is.


Thanks

btanksley@hifn.com wrote:
> 
> 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

-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com