[Seaside] Smalltalk design advice -howtoimplement genericbi-directional pointers?

[Sebastian Sastre]

Hi Aaron,
 
    a comprensible reaction at first but see this subtlelty: the #parent and
#children messages are there but you are the one who decide to use them in
your objects. Probably the framework (who put there that accessors) has it's
reasons to use them but they reasons are not your reasons nor excuses to
lightly include them in your design. Mostly because a matter of being aware
of the consequences of using them (or the inhability of using them).
 
    In smalltalk is useful to maintain allways a quote healthy skepticism
with your own designs/code so you can question it every time you need.
Question you own design is the informal way (and cheap way) of putting it
into a test. Definitive and formal tests came with unit tests and usability
tests.
 
    I know that components hard coupled to children with children loose
copled to parents can scale in comlexity a lot. That's way I'm encouraged to
speak about them. In any parent I sistematically use all the children I
want/need, make convenience accessors or send direct messages. Also I make
children neigh significant announcements or events everytime they happen
(the event or announcement should be named in the perspective of the one who
announces the event and *not* in what listeners wants to hear). This way
anyone can be a listener. Most often will probably be some parent but
sometimes other objects than parents or siblings may be interested in
listening.
 
    I'm surprised about what you say about Apple. I'd expected more from
them. Anyway they probably had some reasons for that it's java after all. I
don't have any idea of where it leads but I smell I don't want to know. I do
have an idea of Smalltalk/Seaside and I know they can allow me to go far.
 
    I think you where not naive but intuitive when thinking about #parent
and #children must exists. It's obvius. The problem is not there but in the
discern of the use of that obvious thing. As a rule of thumb I'll only allow
myself to consider send a direct message to a parent when that children is
only designed for that parent. But I'm aware that is tight coupling by
definition and it's killing any chance of scaling/composing that. Also kills
flexibility. So I also must have enough certainty that they will be not
needed. To have certainty is not easy nor cheap so 100% of the times I
prefer to make a new annoucement for the event, make the children to
announce it when proper and make the parent to listen that event from that
children and take proper reaction.
 
    Some people will "see" that send one "clever" direct message could save
them a couple of dollars of doing a class adding a line in a listening
method and the reaction and announcement methods but they are probably not
seeing the consequences (so costs) of that "cleverness". They probably have
to spend a couple of thounsands in refactoring sometime after when they
realize they have an unflexible and unescalable design.
    
    cheers,
 
Sebastian Sastre


  _____  

De: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] En nombre de Aaron
Rosenzweig
Enviado el: Domingo, 23 de Diciembre de 2007 19:23
Para: Seaside - general discussion
Asunto: Re: [Seaside] Smalltalk design advice -howtoimplement
genericbi-directional pointers?


Hi Sebastian. You just turned my world on its head :-) 

On Dec 23, 2007, at 3:43 PM, Sebastian Sastre wrote:


Almost allways objects should not know about "their parents". But parents

often want to know what is going on with it's children even when the

children do not pass a message "directly" (hard coupling). 


And I just read part of Ramon's blog that says the same kind of thing but
with the specific example of Seaside components and the Announcements
framework:

http://onsmalltalk.com/programming/smalltalk/maintaining-loose-coupling-in-s
easide-components/

This is great, you both make valid arguments. While I understand what you
say my past still haunts me so I popped open the system browser to examine
"WAComponent" which is the general Seaside page component. It's just as you
say. There is a "WAComponent>>children" message and a "WAComponent>>parent"
message is AWOL.

"How can this be?" was my first guttural reaction. 

You see, I'm a WebObjects weenie. "WOComponent" is to WebObjects what
"WAComponent" is to Seaside. In a "WOComponent" you have
"WOComponent.parent()" but you do not have "WOComponent.children()". It's
the exact opposite of what you are recommending and what Seaside is doing.
Combing through the cob webs of my recollection, I remember struggling with
this notion years ago. I naively thought that both relationships should
exist because there were times when I really wanted at the children of a
particular component. And you know, if you dig into Apple's java code,
you'll realize that they do have a hidden concept of children for a
particular component, but they don't expose it in the public API. You kind
of have to know your children when you are asked to generate the HTML
response string and you want to give your "children" components a chance to
"speak". 

So, after I peel back the layers of the onion, I see that Apple consciously
decided components should only know their parent. Yet, behind the scenes,
they secretly have a way to get to the children. Kind of bizarre, I wish I
knew what their design decision was but I don't. I had always just assumed
there was a "very good reason" for modeling components the way Apple did,
but maybe, in light of what you are telling me, there isn't one.


-- Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20071226/7d030885/attachment.htm