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