>
>
> On Mon, Jun 29, 2009 at 8:59 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
>>
>> 2009/6/30 Cameron Sanders <
csanders.personal@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@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 ;)
>