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 ;)



>
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090630/9d373d61/attachment.htm