Hi Trygve

I think that having class extensions is key extensibility of Smalltalk. 
Try to do a Visitor in Java to see what I mean.
Then AspectJ introduces introductions that are essential class 
extensions and lot of people use that because they need it.
Now with package you can control well class extensions.

On 5 mars 04, at 11:46, Trygve Reenskaug wrote:

> 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.

Avi and MC gurus are working on that. But the fact that Squeak did not 
have a package system makes the transition slower, especially because 
we do not want to scare newbies. I suggest you to use Monticello 
because this is the future with SqueakSource
to publish and version you changes. But imagine just that we substitute 
categories by first class packages, that the browser
provides visual clues for class extensions (not based on brittle 
conventions), that you get package dependencies. Then
you could build your application from a set of packages identified 
conflicts.....But this may be a bit more constraining
for the sunday squeakers (I always liked joseph way of insulting 
Squeakers:)).

Stef