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
|