Les Tyrrell wrote:
----- Original Message ----- From: Karl Ramberg karl.ramberg@chello.se To: squeak@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
squeak-dev@lists.squeakfoundation.org