On Feb 14, 2004, at 2:56 AM, ducasse wrote:

>> The problem is that Squeaks current runtime system and development 
>> tools there's no way to annotate these things as belonging to a 
>> particular package. This is why I'm interested in the KCP and browser 
>> rewrites - once we have a way to annotate variables, we can have a 
>> much richer code model for Monticello.
>
> I see.
> Ginsu has that and it would be good to be able to have that too. I 
> think that KCP is cleaning the run-time while what we need in that 
> case is real package holding definition objects which lazzily forward 
> to run-time entities where they are there (as in Ginsu). So I would 
> suggest to make package not only a facade for the system but introduce 
> real objects.
> This also means that we need a browser that manipulates these entities 
> (as in Ginsu). But we could esaily said that class categories have 
> been promoted first class objects = Package.
>
> If you have another solution propose one. I would like to know how we 
> could do that otherwise (ie without compromising the current run-time 
> semantics and in this elegant way). I really think that the semantics 
> model as in ginsu is simple, obvious and nice.

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.

One of the things we tried to do in Monticello is have it be 
independent of the rest of the tools in the system. If somebody invents 
some wonderful new tool for editing code - the RefactoringBrowser, for 
example, he should still be able to use Monticello with it. So I agree, 
some kind of indirection between the browser and the system is a good 
idea, but I don't think it shouldn't be Monticello definitions. (And I 
think this would be true even if we factored the definitions out of 
Monticello and put them in the kernel.)

My hunch is that your mention of "APIs and mirrors" is right, and as 
Avi mentioned, they should be used throughout the system, not just by 
browsers. But I don't really grok that stuff very well yet, and I've 
been deliberately avoiding delving into it until we have a more 
flexible browser implementation.

(Stéphane knows this already, but I haven't mentioned it on the list 
yet: I'm working on a browser implementation that will be easier to 
hack on than what we've got now. The idea is to make it easier to 
create specialized browsers, which should in turn make it easier to 
experiment with the run time: packages that aren't layered on top of 
SystemOrganizer, Traits, mirrors, editing code in remote images, that 
sort of thing. I expect to have a preliminary release ready in the next 
couple of weeks.)

In any case, I think we ought to be moving towards replacing 
PackageInfo with a true Package, and now that we have a robust 
notification mechanism, that's pretty feasible. The future is indeed 
bright.

Colin