2009/6/30 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Mon, Jun 29, 2009 at 8:59 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 2009/6/30 Cameron Sanders <csanders.personal at functional-analyst.com>:
>> > What you write (down below) is close to what I was thinking when I said
>> > have
>> > all #isXXX return false by default;
>> > although I would test that the first two characters match 'i' and 's'
>> > and
>> > that more characters exist, if so, return false, otherwise, normal
>> > #doesNotUnderstand: behavior.
>> >
>> > I would treat #is by itself differently... it is ... or it couldn't be
>> > tested! So I would do nothing for simple #is. and I don't like #is:
>> > because
>> > it looks like a class type test... but that is part of the point, eh?
>> >
>>
>> I wouldn't say that. It is more trait-based approach than class-based.
>>
>> The concept of #is: are: When object foo having some trait, it should
>> answer true on 'foo is: sometrait ', otherwise false.
>> Obviously since most subclasses inherit the behavior & traits of base
>> class, you should honor this rule in overrides of #is: method
>> i.e.:
>>
>> Someclass>>is: object
>>  ^ (your tests here) or: [ super is: object ]
>>
>> otherwise, if you omit the super send, some of the traits will become
>> unavailable. But of course, except when you doing this intentionally.
>>
>>
>> > I'll have to go back to the original example (by siguctua at gmail.com, and
>> > read more about lambdas) but I thought that CVLambda would implement
>> > #isCVLambda  to return true when it can be verified to be one. The
>> > example
>> > did not illustrate #doesNotUnderstand:.
>> >
>> > Back to the question of adding behavior to classes that you don't own.
>> > VisualWorks has a means to extend a class in a different package ... as
>> > I
>> > recall. As I recall, squeak has no such capability, right?
>> >
>>
>> MC having this capability for a years.
>
> 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.
> The VW "solution" 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's parcels are intensional, MC
> packages are extensional.  There's a tension in both; many VW'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.
> When you also provide selector namespaces I don'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 ;)
>

i just wanted to point that MC having an extension mechanism. Yes, it
is different from VW one.
And in the light of your description - it is done wrong (at least for
me), but its still can be called 'extension mechanism' :)

>>
>>
>> > Thanks. You have given me food for thought...
>> >
>> > Ciao,
>> > Cam
>> >
>> > On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:
>> >
>> >> What I typically what I've been doing to eliminate all of these methods
>> >> with a single simple change:
>> >>
>> >> Object
>> >>   doesNoUnderstand: aMessage
>> >>       ^ false
>> >
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.