Hi Lex!

Sorry for having answered so lately. I did not see your email before. I am still wondering why...

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

Right. The tools have to help the programmer.

> 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 agree completely. These are issues related to the developing environment.
However, it is not because an imported class is not used that it should not be imported. You want your model to define a proper public interface, which is not always the smallest one.

The user should have a way to "clean" and the tool should help him. But this last does not have to do it automatically.


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

I agree. The Classbox module system is a packaging mechanism. It helps people to (1) organize and structure their application, and to (2) provide some unanticipated changed on an application.

The only way to know if a model can support very large amount of code, is to try it...

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

Oh yes!

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

A class is not a classbox/module. I believe that a class should not have any import clause.

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

Yep. In that way are utilised only what is necessary.


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

This is something included in the theorical model of the classbox (described in the paper). However the current implementation does not reflect this feature yet. 


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

Yes.


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

I agree too. That is why we would like to add interfaces to classboxes.

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

I expect this issue to have a broader impact: a module system does not make code safer. Even if it might effectively help, it is not its primarly goal. It is intended to make concurrent development, deployment and reuse much easier.

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

I do not get this one...


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

Yep. This open the door to (un)load dynamically modules... something that might be useful for a component model. For instance, you would like to unload properly a squeak project aren't you?



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

Yes yes yes. We are aware of that. This is something that we really have in mind, but it is not described in our papers. Basically, you are referring a version mechanism for classboxes. 

For instance, you want to provide a better Socket>>ping that use the ICMP protocol instead of the TCP one. In that case, you think that is should be a good idea to make your patch global. In that case you just want to evolve the Network Classbox.


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

Okay but I do not see this as related to a global change. Basically you would treat this issue using a registration mechanism. And not by recompiling a method...


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

Yep, and we are clearly not against that. Classboxes are just a new born model. 

Most of the work need to be done on the tools support. And I do not have the force for doing it.

> -Lex

Best Regards,
Alexandre




-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.