[squeak-dev] Future of Squeak, and outsider's view

Eliot Miranda eliot.miranda at gmail.com
Tue Jun 30 17:46:39 UTC 2009


On Tue, Jun 30, 2009 at 10:33 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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' :)


then +1 :)


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


More information about the Squeak-dev mailing list