Smalltalk & Squeak featured on Slashdot

Karl Ramberg karl.ramberg at chello.se
Mon Apr 30 18:26:25 UTC 2001



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

> 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