<html>
    <head>
        <title></title>
        <link href="/de/FCKeditor/editor/css/fck_editorarea.css" rel="stylesheet" type="text/css" /><style media="screen" type="text/css">
body {font-family: verdana, arial, helvetica, sans-serif;font-size: 12px;padding: 5px;margin: 0;background-color: #FFF;}
p, ul, li {margin-top: 0;margin-bottom: 0;}
blockquote {margin-left: 5px;}
div.signature {color: #666;font-family: monospace; font-size: 0.9em;}
</style>
    </head>
    <body>
        &gt; This sounds, to me at least, to be suggesting that an accessor should be<br /> &gt; implemented only if you want to expose that &quot;implementation detail&quot; for<br /> &gt; use by other objects. Am I misinterpreting the statement?<br /><br />Not the implementation detail but the accessibility of an instvar. I meant that I want an accessor implemented whenever the accessibility of an instVar should be granted to outside senders. Other way around: Is an instVar internal then it's acceptable NOT to have an accessor. <br /><br />See the example I gave about instVar fields in WARequest:<br /><br />1) In the current implementation external classes say:<br /><span style="font-weight: bold;">aRequest fields at: #someValue -&gt; very bad!</span> <br /><br />It spreads knowledge about over foreign classes. That cannot be seriously considered acceptable Smalltalk style!&nbsp;This requires others to know the implementation details of fields in WARequest. Violates encapsulation badly1<br /><br /><span style="font-weight: bold;">2) I proposed either of these:</span><br />a) aRequest fieldsAt: #someValue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; well, ok, ca vas<br />b) aRequest get: #someValue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; much better<br />c) aRequest someValue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt; best of all<br />where the third one has the advantage that the implementation of the storage of this symbol inside WARequest is even better hidden. We have implemented b) and c) depending on the situation.<br /><br />Please read my post!<br /><br />In my experience it happens only in very rare cases that one (or I here) wants to hide the instVar <span style="font-weight: bold;">values</span> from the outside. But one should <span style="font-weight: bold;">always hide the implementation details</span>! This is frequently not the case in Seaside.<br /><br />See my post &quot;Proposal 4: Class WARequest&quot;. It comprises of <span style="font-weight: bold;">9 concrete proposals</span> and <span style="font-weight: bold;">only this one was discussed</span> here. Not to mention the other proposals. And still no comment at all on failing to document!<br /><br />A bad sign proving how little open minded most contributors are on this list. Unfortunately!<br /><br /><br /><br />-------- Original-Nachricht --------<br />&gt; Datum: Sat, 18 Apr 2009 15:29:00 -0400<br />&gt; Von: Richard Peirson &lt;richardpeirson@gmail.com&gt;<br />&gt; An: Seaside - general discussion &lt;seaside@lists.squeakfoundation.org&gt;<br />&gt; Betreff: Re: [Seaside] A new critical blog discussing Seaside - Using &nbsp;&nbsp;&nbsp; getters/setters<br /><br />&gt; I agree entirely with the points being made by both Michael and Frank on<br />&gt; this topic.<br />&gt; <br />&gt; In fact, based upon this quote taken from Mr. Cucumber's Proposal #1 in<br />&gt; his<br />&gt; Blog, it appears that he does too . . .<br />&gt; <br />&gt; 7) Accessors for other internals<br />&gt; Of course, the same as stated in 6) is true for all other instances held<br />&gt; by<br />&gt; WARequest in its instances. It is never good to let foreigners (classes<br />&gt; outside WARequest) know about implementation details inside another class!<br />&gt; To reming [sic] you: This is what is called encapsulation in the<br />&gt; schooldays<br />&gt; for Smalltalk.<br />&gt; <br />&gt; This sounds, to me at least, to be suggesting that an accessor should be<br />&gt; implemented only if you want to expose that &quot;implementation detail&quot; for<br />&gt; use<br />&gt; by other objects. Am I misinterpreting the statement?<br />&gt; <br />&gt; On Sat, Apr 18, 2009 at 3:05 PM, &lt;TheSmalltalkBlog@gmx.ch&gt; wrote:<br />&gt; <br />&gt; &gt; Once again:<br />&gt; &gt;<br />&gt; &gt; There is no performance difference between accessors and direct<br />&gt; instVars!<br />&gt; &gt;<br />&gt; &gt; Was all tested by us many years ago, because this issue was brought up<br />&gt; as a<br />&gt; &gt; concern. Even dicts for instVars don't really make a difference (very<br />&gt; little<br />&gt; &gt; impact and no practical issue compared to the advantages). All for VW<br />&gt; only.<br />&gt; &gt;<br />&gt; &gt;<br />&gt; &gt; -------- Original-Nachricht --------<br />&gt; &gt; &gt; Datum: Sat, 18 Apr 2009 20:55:20 +0200<br />&gt; &gt; &gt; Von: Claus Kick &lt;claus_kick@web.de&gt;<br />&gt; &gt; &gt; An: Seaside - general discussion &lt;seaside@lists.squeakfoundation.org&gt;<br />&gt; &gt; &gt; Betreff: Re: [Seaside] A new critical blog discussing Seaside -<br />&gt; &gt; Using&nbsp;&nbsp; getters/setters<br />&gt; &gt;<br />&gt; &gt; &gt;<br />&gt; &gt; &gt; How much difference does the extra method send make in VW, speedwise?<br />&gt; Is<br />&gt; &gt; &gt; this measureable somehow?<br />&gt; &gt;<br />&gt; &gt; --<br />&gt; &gt; Psssst! Schon vom neuen GMX MultiMessenger geh&ouml;rt? Der kann`s mit<br />&gt; allen:<br />&gt; &gt; http://www.gmx.net/de/go/multimessenger01<br />&gt; &gt; _______________________________________________<br />&gt; &gt; seaside mailing list<br />&gt; &gt; seaside@lists.squeakfoundation.org<br />&gt; &gt; http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br />&gt; &gt;<br />
    <div class="signature"><br /><br /><br />-- <br />Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01</div></body>
</html>