Binaries in Monticello

Julian Fitzell julian at beta4.com
Mon Feb 16 20:22:00 UTC 2004



C. David Shaffer wrote:
> Colin Putney wrote:
> 
>>
>> Some thoughts about this:
>>
>> I think packages should be orthogonal to class categories. When 
>> browsing just one package, it's still quite useful to be able to group 
>> classes, and it would also be nice to be able to do it in terms of the 
>> entire system. For example, I might like to add a new kind of 
>> Magnitude as part of my package, and classify it that way, but still 
>> have it show up as part of my package.
>>
>>
> Colin,
> 
> Why can't you do this with the current system?  Subclass PackageInfo and 
> override #classes.

You can, but would you go to the effort?  I wouldn't...

> You're suggesting tool support then that reminds me of the VisualWorks 
> StORE system...and it was not well received at all.  Just search the 
> vwnc mailling list.  I don't have strong opinions on it myself but I 
> believe that the detractors say that it makes one too many views 
> available for the novice user.  There are probably other objections as 

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

> well.  Would you propose, for example, another browser akin to the 
> Package Pane Browser?  Personally, if StarBrowser could browse all 
> components of a Package (as expressed in PackageInfo) then I would be 
> pretty happy with it.  Maybe this has already been done?

Exactly, the browsers just need to be package aware.  And if you make 
packages first-class citizens, they would be.  Packages wouldn't be 
optional features, they're just the things in which classes and method 
extensions live.

Julian



More information about the Squeak-dev mailing list