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
squeak-dev@lists.squeakfoundation.org