On Feb 16, 2004, at 12:22 PM, Julian Fitzell wrote:

> I don't know StORE, so I don't know how similar it is, but it seems to 
> me that you end up always working in a package.  It's not another view 
> for a novice user, they just create a package (or there's a default 
> package, whatever) and all the code you write ends up being in that 
> package.  I don't think novices need to know any more than that.  More 
> experienced folks would need to know that if they want to make changes 
> to the base system, they should actually be in the appropriate base 
> package, etc...

Yes, I think having the tools organize around the idea of "current 
package" is a very good way of managing the complexity.  You open a 
browser on a package and it still shows all the 
categories/classes/methods as normal, but any item that belongs to the 
current package or has members that belong to the current package will 
show up in bold (or in black vs grey, or something).  Then there could 
be a simple context menu item for "add to current package"/"remove from 
current package".

That works best if your packages are large - if you start getting too 
fine a granularity it breaks down.  I wonder if you could unify the 
idea of category and subpackage?  So, Colin talked earlier about adding 
something to the Magnitudes category, say from the Monticello package.  
Maybe that becomes the Monticello.Magnitudes subpackage, which is 
different from the Core.Magnitudes subpackage?  But that's getting 
ahead of ourselves...