<br><br><div class="gmail_quote">On Mon, Jun 29, 2009 at 8:59 PM, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/6/30 Cameron Sanders &lt;<a href="mailto:csanders.personal@functional-analyst.com">csanders.personal@functional-analyst.com</a>&gt;:<br>
<div class="im">&gt; What you write (down below) is close to what I was thinking when I said have<br>
&gt; all #isXXX return false by default;<br>
&gt; although I would test that the first two characters match &#39;i&#39; and &#39;s&#39; and<br>
&gt; that more characters exist, if so, return false, otherwise, normal<br>
&gt; #doesNotUnderstand: behavior.<br>
&gt;<br>
&gt; I would treat #is by itself differently... it is ... or it couldn&#39;t be<br>
&gt; tested! So I would do nothing for simple #is. and I don&#39;t like #is: because<br>
&gt; it looks like a class type test... but that is part of the point, eh?<br>
&gt;<br>
<br>
</div>I wouldn&#39;t say that. It is more trait-based approach than class-based.<br>
<br>
The concept of #is: are: When object foo having some trait, it should<br>
answer true on &#39;foo is: sometrait &#39;, otherwise false.<br>
Obviously since most subclasses inherit the behavior &amp; traits of base<br>
class, you should honor this rule in overrides of #is: method<br>
i.e.:<br>
<br>
Someclass&gt;&gt;is: object<br>
  ^ (your tests here) or: [ super is: object ]<br>
<br>
otherwise, if you omit the super send, some of the traits will become<br>
unavailable. But of course, except when you doing this intentionally.<br>
<div class="im"><br>
<br>
&gt; I&#39;ll have to go back to the original example (by <a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>, and<br>
&gt; read more about lambdas) but I thought that CVLambda would implement<br>
&gt; #isCVLambda  to return true when it can be verified to be one. The example<br>
&gt; did not illustrate #doesNotUnderstand:.<br>
&gt;<br>
&gt; Back to the question of adding behavior to classes that you don&#39;t own.<br>
&gt; VisualWorks has a means to extend a class in a different package ... as I<br>
&gt; recall. As I recall, squeak has no such capability, right?<br>
&gt;<br>
<br>
</div>MC having this capability for a years.</blockquote><div><br></div><div>Arguably not.  (BTW VW has had it from 98).  The crucial difference is that in VW an extension can be in more than one package.  In Squeak a selector can only be in a single Monticello extension category.  That leads to the awful bug that when an MC package patches a base selector to extend it to fix a bug it ends up in the package and its membership of the package it was in previously being lost.  I understand that with method history this situation can be detected but if you e.g. condense changes then that history is lost, and the base package selector becomes only an extension  Ouch.</div>
<div><br></div><div>The VW &quot;solution&quot; is OK as far as it goes; a package is a set of class, selector pairs (more than this, but this is the essence).  An MC package is defined by class and method categories.  VW&#39;s parcels are intensional, MC packages are extensional.  There&#39;s a tension in both; many VW&#39;ers want, at least at the UI level, for packages to be extensional, but precision (knowing whether something is in a package or not, allowing things to be in more than one package so that one can include patches, etc) requires an intentional construct.</div>
<div><br></div><div>When you also provide selector namespaces I don&#39;t think the situation changes because one still needs patches in the absence of a perfectly designed system.  So IMO somehow MC needs to move to an intensional package definition, at least for extensions ;)</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="im"><br>
&gt; Thanks. You have given me food for thought...<br>
&gt;<br>
&gt; Ciao,<br>
&gt; Cam<br>
&gt;<br>
&gt; On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:<br>
&gt;<br>
&gt;&gt; What I typically what I&#39;ve been doing to eliminate all of these methods<br>
&gt;&gt; with a single simple change:<br>
&gt;&gt;<br>
&gt;&gt; Object<br>
&gt;&gt;   doesNoUnderstand: aMessage<br>
&gt;&gt;       ^ false<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
<br>
</div><div><div></div><div class="h5">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>