<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3243" name=GENERATOR></HEAD>
<BODY 
style="WORD-WRAP: break-word; webkit-nbsp-mode: space; webkit-line-break: after-white-space">
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>Hi Aaron,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp;&nbsp;a comprensible reaction at 
first but see this subtlelty:</SPAN></FONT><FONT face="Trebuchet MS" 
color=#0000ff size=2><SPAN class=578473012-26122007> 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).</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp; 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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp;&nbsp;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&nbsp;use all the children I want/need,&nbsp;make convenience 
accessors or&nbsp;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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT><FONT 
face="Trebuchet MS" color=#0000ff size=2><SPAN class=578473012-26122007>I'm 
surprised about what you say about Apple. I'd expected more from them. Anyway 
they probably had some reasons for that&nbsp;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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp; I think you where not naive but 
intuitive&nbsp;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.&nbsp;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&nbsp;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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT color=#0000ff><FONT 
size=2><FONT><SPAN class=578473012-26122007>&nbsp;&nbsp;&nbsp; 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".</SPAN></FONT>&nbsp;<SPAN 
class=578473012-26122007>They probably have to spend</SPAN><FONT><SPAN 
class=578473012-26122007> a couple of thounsands in refactoring sometime after 
when they realize they have an unflexible and unescalable 
design.</SPAN></FONT></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN 
class=578473012-26122007>&nbsp;&nbsp;&nbsp; cheers,</SPAN></FONT></DIV>
<DIV><FONT face="Trebuchet MS" color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV align=left><SPAN class=250542422-20122006>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><?xml:namespace prefix 
= st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:PersonName 
ProductID="Sebastian Sastre&#13;" w:st="on"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'">Sebastian 
Sastre<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></SPAN></st1:PersonName></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"><o:p></o:p></SPAN></P></DIV></SPAN><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=es dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>De:</B> seaside-bounces@lists.squeakfoundation.org 
  [mailto:seaside-bounces@lists.squeakfoundation.org] <B>En nombre de </B>Aaron 
  Rosenzweig<BR><B>Enviado el:</B> Domingo, 23 de Diciembre de 2007 
  19:23<BR><B>Para:</B> Seaside - general discussion<BR><B>Asunto:</B> Re: 
  [Seaside] Smalltalk design advice -howtoimplement genericbi-directional 
  pointers?<BR></FONT><BR></DIV>
  <DIV></DIV>Hi Sebastian. You just turned my world on its head :-) 
  <DIV><BR>
  <DIV>
  <DIV>On Dec 23, 2007, at 3:43 PM, Sebastian Sastre wrote:</DIV><BR 
  class=Apple-interchange-newline>
  <BLOCKQUOTE type="cite">
    <P style="MARGIN: 0px"><FONT style="FONT: 12px Helvetica" face=Helvetica 
    size=3>Almost allways objects should not know about "their parents". But 
    parents</FONT></P>
    <P style="MARGIN: 0px"><FONT style="FONT: 12px Helvetica" face=Helvetica 
    size=3>often want to know what is going on with it's children even when 
    the</FONT></P>
    <P style="MARGIN: 0px"><FONT style="FONT: 12px Helvetica" face=Helvetica 
    size=3>children do not pass a message "directly" (hard coupling).<SPAN 
    class=Apple-converted-space> </SPAN></FONT></P></BLOCKQUOTE></DIV><BR></DIV>
  <DIV>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:</DIV>
  <DIV><BR class=webkit-block-placeholder></DIV>
  <DIV><A 
  href="http://onsmalltalk.com/programming/smalltalk/maintaining-loose-coupling-in-seaside-components/">http://onsmalltalk.com/programming/smalltalk/maintaining-loose-coupling-in-seaside-components/</A></DIV>
  <DIV><BR class=webkit-block-placeholder></DIV>
  <DIV>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&gt;&gt;children" message and a 
  "WAComponent&gt;&gt;parent" message is AWOL.</DIV>
  <DIV><BR class=webkit-block-placeholder></DIV>
  <DIV>"How can this be?" was my first guttural reaction. </DIV>
  <DIV><BR class=webkit-block-placeholder></DIV>
  <DIV>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". </DIV>
  <DIV><BR class=webkit-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><FONT face="Trebuchet MS" color=#0000ff size=2></FONT><BR 
  class=webkit-block-placeholder></DIV>
  <DIV>-- Aaron</DIV></BLOCKQUOTE></BODY></HTML>