This comment may be out of scope, but I believe the thread rises an 
important issue.

The idea of letting a package add methods to other (base) classes reminds 
me of MC Windows. When I install a SW product, the windows installer puts 
some of the program in a directory of my choice. It also puts stuff into 
the Registry, adds some files under C:\, and adds DLLs and other stuff all 
over the shop. The uninstall feature works some of the time; it rarely 
removes all that should be removed and is very sensitive to obscure errors. 
And how many people know how to identify garbage in the Registry and remove 
it safely?

I neither control the Registry nor the files in my Windows system. Combine 
with a firewall like a sieve: Anybody can put anything into my personal 
computer without me knowing anything about it.

I hate it, and suspect Squeak is heading in the roughly the same direction. 
I looked at class PackageInfo, the class comment says: "Subclass this class 
to create new Packages." Very instructive. I suspect PackageInfo serves the 
same purpose as the install/uninstall files of Windows.

Consider Object>>'*connectors-message handling'>>withEnoughArguments:. A 
convenient method that anybody might be tempted to use. Remove the 
Connectors package, and where are you? (There is a subclass of PackageInfo 
for Connectors). I call this an obscure dependency and suggest we prohibit 
it. Either extend base classes with new and useful methods or use some 
other mechanism such as subclassing or delegation.

I would like to see Squeak becoming main stream (Dynabook 20xx), may be 
some of you share this vision. We need a package concept that is safe from 
hackers. Safety has to be designed in right from the start, it cannot be 
added as an afterthought. (You don't want to be like Windows, do you?) 
Packages are about source code. Squeak is about objects. I suggest we look 
for a module concept that is more object-like. A starting point could be 
the UML 2.0 Component.

--Trygve

At 04.03.2004 11:38, you wrote:

>On Mar 4, 2004, at 10:44 AM, ducasse wrote:
>
>>Because it was introducing dependency between the browser and the core of 
>>class. This is like having a popUp menu
>>in the middle of some deep class functionality.
>
>No, it's really not.  It doesn't introduce  any dependencies.  It's a 
>completely separate method that isn't sent by any of the "core" methods of 
>Object.  There's no reason to remove it.  If you're concerned about 
>marking it as part of the Browser package rather than the Kernel package, 
>we have mechanism for doing that - put it in a method category labelled 
>'*tools-browser'.  But please, please, don't confuse which class a method 
>is on with which package it's in.  You know better than that, Stef:  I 
>expect that kind of argument from newbies complaining about #isMorph, not 
>from a seasoned Smalltalker.  And "we don't have a package system in the 
>base" is both incorrect (PackageInfo is meant for exactly this purpose) 
>and a poor excuse (if we start destroying the design of the system because 
>we don't have a package system now, how will we fix it once we do?).
>
>I hugely appreciate the work that KCP does, but removing methods like that 
>is counter productive.  Let's put it back, properly categorized, and if 
>there are any similar removals that KCP has done we need to know about 
>them so we can reverse them too.  Please.
>
>Avi
>
>


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway