Smalltalk & Squeak featured on Slashdot

Karl Ramberg karl.ramberg at chello.se
Mon Apr 30 19:51:04 UTC 2001



Les Tyrrell wrote:
> 
> ----- Original Message -----
> From: Karl Ramberg <karl.ramberg at chello.se>
> To: <squeak at cs.uiuc.edu>
> Sent: Monday, April 30, 2001 1:26 PM
> Subject: Re: Smalltalk & Squeak featured on Slashdot
> 
> >
> >
> > Les Tyrrell wrote:
> > >
> > > Glyph Lefkowitz wrote:
> > > >
> > > > On Monday 30 April 2001 03:55, Stephane Ducasse wrote:
> > > > > And this would be great to have classes that have less than 200 methods ;).
> > > > > In the same idea, I strongly think that string does not have to know
> > > > >     asURL
> > > > >     as....
> > > > >     asblabla
> > > > >
> > > > > Because then everything is linked together.
> > > >
> > > > I doubt that this is feasible w/ squeak, but in a perfect world, asURL
> > > > asBlaBla and friends *would* be part of String, but they would also have a
> > > > module they were associated with; so you could browse methods by class or by
> > > > module.  In theory, module dependencies could be automatically computed,
> > > > then...
> > >
> > Wouldn't these thing be easier if there was sideways relation,
> > inheritance from several classes ?
> >
> > Karl
> 
> In this case, I would argue against that- the problem, as I see it, is that these methods
> fundamentally do not belong where they are being found.  This is a symptom of a bad design, not a
> tools issue per se.  Where I would argue that tools have a role in this is to discover where such
> things are going on, and to make this sort of thing more visible to the programmer in a way that
> clearly depicts this as NOT being the preferred manner in which to introduce new capabilities into
> the image.   That is the angle I am taking with Oasis, as described a bit below.
> 
Ok. The funktionality in Oasis seem really cool. What would the image
size be if 
you ran this after major shrink and deleted all the fluff?
Karl
> - les
> 
> > > These things are basically possible.
> > >
> > > If you take a chunk of code which represents the most visible bits of functionality of
> > > some prospective module, you will discover within it usage of certain selectors in certain
> > > contexts.  These can be located, and it is possible to identify these with both their
> > > usage and their implementations.  Do enough of this, and you can probably assign chunks of
> > > selectors ( call them interfaces if you wish ) to both the module which uses them (
> > > exclusively, perhaps ) and the classes which have been extended to support such modules.
> > > I developed just such an analytical capability in Oasis for just this sort of task- it was
> > > meant to assist in the modularization of lots of non-modular code.  When I started it, I
> > > thought I would be mainly interested in VisualWorks, but since then the same sorts of
> > > problems have begun to plague Squeak to an even greater extent.
> > >
> > > If you do this, then you have knowledge of which selectors are extensions and which are
> > > intrinsic properties of the various "base" classes.  You then "know" more clearly what
> > > belongs in those "base" classes, and what is fluff- too much fluff is not a good sign.
> > >
> > > > It's really powerful to be able to add methods to Object, sometimes; but it
> > > > would be really neat if you could take those methods *OFF* too :)
> > >
> > > If you know which ones they are, this is trivial.
> > >
> > > - les
> >





More information about the Squeak-dev mailing list