[Seaside] Smalltalk design advice - how to implement genericbi-directional pointers?

[Ramon Leon]

> How can I make this relation-management code generic, so I 
> can easily add it to any class with any named accessors, any 
> number of times? I prefer to avoid DNU approaches if possible 
> as this code will be called in several inner loops that need 
> to run fairly tight. I thought traits might help but now 
> don't think so.
> 
> Thanks - Sophie 

You can't, what you're looking for are macro's to generate this boilerplate
for you and Smalltalk doesn't do that.  The Smalltalk way (if you must do
this) would be to reify the relationships as objects and do this at runtime
via dnu.  This is exactly what my Tsuanami package on SqueakSource/SqueakMap
does.  Take a look at the unit tests to see examples.  

However, a better solution, one that relies on real code and not dnu, is to
stop thinking objects are relational tables and start thinking in objects.
Rooms don't know what house they're in, tires don't know what car they're
on, products don't know what basket they're in, line items don't know what
order they belong to.  They don't need to, because if you have access to a
room/tire/product/line item, it's because you already have the
house/car/basket/order object.  The house/car/basket/order is the aggregate
root, it's the meaningful object. It's composite parts are only interesting
in relation to their parent and ideally only accessible through their
parent.  

Other objects should not reference the children of an aggregate, only the
aggregate itself.  This being the case, they don't need to know how their
parent is.  They're actually more composeable and better objects when they
don't.  I should be able to remove a room/tire/product/line item from one
house/car/basket/order object and put it into another house/car/basket/order
object without any weird side effects like on of them pointing to the wrong
parent.  

Objects are not tables and bi-directional relationships, in general, are not
desirable.  If I'm building a house, do I do this...

    aHouse addRoom: aRoom

Or this...

    aRoom house: aHouse

The simple answer is, make up your mind which one makes more sense in the
situation and do that one only.  Do not allow both, a model has little
meaning if it doesn't guide you in a particular direction and just allows
anything.

Ramon Leon
http://onsmalltalk.com