Thanks, Stephane and Alex.  This helps a lot.   

I have a couple of notes.  Maybe you've already thought about them, but
they are important (to me) so I'll toss them out just to be sure.



> > 	3. Letting users start coding quickly?  e.g., how much overhead is
> > there to create a dumb little subclass of Morph that responds to button
> > clicks by opening a web browser?
> 
> Evaluate the following in a workspace after having loaded Classbox from SqueakMap and evaluated 'Classbox hookClassboxModel'
> Note that the two last expressions are equivalent in that example.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> |cb|
> cb := Classbox create: #MyGreatButtonClassbox.
> cb import: #Morph from: Classbox system.
> cb import: #PluggableButtonMorph from: Classbox system.
> cb import: #Transcript from: Classbox system.
> cb createClassNamed: #MyGreatButton superclass: #Morph.
> 
> cb addMethod: 'initialize
>   super initialize.
>   self addMorph: (PluggableButtonMorph on: self).
>   self bounds: ((100 @ 50) extent: (100 at 50))' for: #MyGreatButton.
> cb addMethod: 'isOn ^true' for: #MyGreatButton.
> cb addMethod: 'switch Transcript show: ''Blah blah'';cr' for: #MyGreatButton.
> cb addMethod: 'open self new openInWorld' for: #'MyGreatButton class'.
> 
> cb evaluate: 'MyGreatButton open'.
> (cb at: #MyGreatButton) open
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


This requires more steps than are currently required; specifically, the
imports add extra steps.  Later you mention that you do have some
support for letting people type the code first, and then have the tools
query you for what imports to add if you are missing some imports.  So
the extra import steps can be deferred, and the tools can help you
through the process.



> > 	4. Letting users manage the system after it has been running a while
> > and acreating any gunk that #3 will impose?
> 
> I do not understand it. I have an English question, what is a "gunk"?

Heh, you both asked.  Look under the keys of a well-used keyboard for an
example.  :)

What I mean is, if the tool is automatically adding a lot of imports for
you, then eventually you might like to clean house and get rid of
imports you don't need.  You might also like to move some classes
between different namespaces.    Stuff like that.

I am being vague, I admit.  The bigger issue is *maintenance* of code. 
Most discussions here are focussing on initial entry -- which I agree is
very important -- but there is also an isuse of maintaining large
amounts of code once it has been written.  I don't know exactly what
people will want to do, so my questions are a little vague.  It's hard
to predict what operations people will want to do.

Two things that seems important, however, are that the mechanism is
comprehensible, and that the mechanism doesn't lead to large amounts of
any particular item.  As an example of comprehensibility, it is
important that imports not be completely hidden away by the browsers;
developers should have a way to find out what things they are linking
in, and it shouldn't require scanning through each method one by one. 
As an example of large amounts of stuff, it would be bad to have
thousands of imports being common for a single class; no matter how good
the tools are, this sounds like too much to work with.



> > How do I write code that uses Tweak classes, from outside of Tweak,
> > without having to fully qualify all of my references?  Am I forced to
> > import one class at a time?
> 
> If you want to use a class A provided by a classbox CB1 in your classbox CB2, you need to import it.

Okay, so it's one class at a time.

Importing entire classboxes, as I'm sure you have considered, seems to
have both good and bad.  I suspect the good will win; it would be very
nice if a new Tweak user can just "import Tweak" and start running. 
Better, it would be good if you could set up an image so that it imports
Tweak by default in new class boxes.

The big downside is that you have to deal with conflicting names in
multiple imports; you are sure to import more than you need if you
import in big hunks like this.

As a mitigation, note that tools can figure out which fragments of a
classbox you are actually using.



Aside from class boxes in particular, you have a great analysis here of
what is good in a packaging system here.  Go go go!  :)  I got thrown by
the word "deploy", which seems odd for source code to me; applications
are deployed, and source code is usually more *shared*.  It is usually
expected that someone who receives source code is going to feel free to
modify it.

Anyway, a few quick comments on packages, too:


> For instance, dependencies has to be set up manually, and so
> whatever the code contained in a package. This mean that I
> can create a ButtonMorph in my package but setting a
> dependency with the Network package rather than with Morph
> for instance. 

Yeah, you'd like at least a warning.

Note that some dependencies have to be added manually -- you may
reference class URL but realize that you will pass it a lot of HTTP
url's; thus, you would want HttpUrl's to be loaded as well.  (Well,
HTTPUrl would probably be included by default anyway, but I hope this
gives the idea.)

Also, you may consider not going for the complete grail of "if my
dependencies are there, I will definitely work".  Software is just too
unreliable for that.  If you want a reliable combination of packages,
then in the end you need to test that exact combination and make sure
that it works.  So please choose a goal that is attainable, lest you
force yourself into corners that you didn't need to.  Package
dependencies, IMHO, should attempt to avoid common errors, not protect
against all possible errors.



> The second point is about unloading package. As far as I have seen (but please let me know if I am wrong), Monticello does not manage that properly in the sense that: if I load sequentially 10 packages that override a method foo, unloading some of them does not always give an expected result. If I am wrong, please show it to me with a SUnit test.

I don't know, but it's a very nice property for any package system that
attains it.



> This means that if in your squeak you have an application
> managing a nuclear powerplant, _loading_ a "EvilClassbox"
> should not break or disturbe anything. 

That is a useful property, but you don't always want it.  Sometimes when
you load a package into an image you *want* things to change.

As a small example, if you load Celeste then you want the "open" menu to
display a new option.  While this sounds innocuous, it is certainly a
change; if 8-bit characters are used in the display name this could even
crash the image.

As a more difficult example, you might want to distribute a bug fix or a
performance enhancement.  You'd still like the other package properties
mentioned above, i.e. dependencies and ability to unload, but you do in
fact want it to be allowed to mess with other stuff in the image.

You may very well deside that things in this last category just are not
packages, but insteuad are some form of diff.  That is fine, but be
aware that this is common behavior when software developers work
together.  Squeak's image has over 5000 patches applied to it at this
point!

-Lex