On Feb 13, 2005, at 3:21 AM, stéphane ducasse wrote:

>> I agree to a large extent.  At least the simple stuff that 
>> PackageInfo knows how to do on its own -- show the code it contains, 
>> show its name, show its comment, be able to unload itself -- ought to 
>> be doable in a Package Browser tool completely separate from 
>> SqueakMap.  (A Package Browser would list the PackageInfos comprising 
>> all of the code in the image.)
>
> By the way alex will certainly release some code to support for a real 
> package class and this will be a good start to have a better support 
> for MC. Mike was doing the same so we are trying to merge effort.
> The idea is that we can then avoid to have category but first class 
> objects instead.
> Alex can we have initialization with your approach? I guess yes but 
> not as method of a subclass so may be this would be a nice idea to 
> have a package been a subclass of Package.

Is this Alexandre Bergel or a different Alex?  Let's see the code! :)  
It doesn't have to be perfect or finished.  It needs to be able to work 
with MC & existing browsers without major changes, at least.  
(Requiring small changes to MC or browsers would okay.)

In any case, we can proceed with PackageInfo (perhaps *slightly* 
modified), and then if a better package object comes along (such as 
Alex's), early enough in the process, we can convert the PI instances 
to the new object.

>> Just so it's clear, I think the situation would be this:
>>
>> The partitioned image would have a global list of PackageInfo 
>> instances.  These PI instances (with names like 'Morphic', 
>> 'Graphics', etc) would define ALL of the source code in the image.  
>> Also, every method in the Basic image would belong to ONE package.  
>> (I don't think there'd be any reason to use PI method overrides 
>> within the Basic image, at least.)
>
> It depends because may be you will face cases where a method has in 
> fact two behavior and one part depends on the presence of another 
> package.

Good point.  I would hope that these situations would be rare enough 
that you could refactor the code into two methods, so that the two 
behaviors are separate and a "method override" is not needed.  But we 
will see.  I suppose this may be somewhat common, but we should see if 
we can try to refactor things so that no overrides are needed in the 
Basic packages.

(And of course we are just talking about method "overrides" here, not 
method "extensions" (additions), such as Object>>inspect.  But you know 
this.  Extensions will be allowed within the Basic packages, of course, 
although we should try not to have *too* many of those either.)

>> (Mm, the browsers will probably still let you create a new class 
>> category without a new PI instance, so you'd have code outside of any 
>> package... that would need to be tightened up.)
>
> This should not. Else this will be the mess.

Yep, that shouldn't happen.  This is where a real package object would 
help.  But we could probably manage to enforce this with PI if we have 
to.

>> If you had SqueakMap installed (which you would in a Basic image), 
>> that would have its list of SMPackage instances, which would contain 
>> the SMPackages pointing to the above PackageInfo instances, plus 
>> possibly a mishmash of other SMPackages (changesets, projects, etc) 
>> which happened to be loaded but which are not PI-related packages.
>
> I do not understand why you need SM to have a list of packages inside 
> the image. You should have all the categories as packages and they may 
> or not be saved as SM packages.

I agree.  The list of PI packages inside the image is currently in 
PackageOrganizer, which is separate from SM.  If you don't have SM 
loaded, the PI packages will still be there.  You could create your own 
internal packages in your image which do not have a corresponding 
SMPackage if you wanted.  (But if you did have SM loaded, all of the 
standard Basic packages (e.g. Morphic) would have corresponding 
SMPackages, of course.)  For now, *some* package metadata (such as URL, 
License, etc) will only be in the SMPackage... I think that is 
acceptable.  You don't really need to have *all* of this sort of 
metadata in the in-image PI package.

Of course, maybe this will all change if we have a real package object, 
but for now, I think this is a workable solution.

> I think that if you want to partition the image and you start to want 
> to support sar, changeset, ... as packages you will die. Why not take 
> the simple idea that a category is a package as in MC?

Agree 100%, the PackageOrganizer list of PI packages will only be 
PackageInfo (and maybe subclass) instances, no changesets or anything 
else.

Hmmm, will a package like Morphic need any artibrary files attached to 
the package, such as a graphic for the trash can?  How would we handle 
this?

>> Is there a situation where you'd have the global list of PI instances 
>> in a more minimal image, but not have SqueakMap installed?  Could be, 
>> but that might be uncommon.  I was thinking that the Minimal image 
>> would still have the PI instances, which means PackageInfo would need 
>> to be part of the Kernel, but I don't know if that's necessary.  As 
>> long as it can add code to itself.  (That is when we take a serious 
>> look at Spoon. :) )
>>
>>> Everyone seems to agree with #1.  #2 is contentious, so consider this
>>> email to be my 2 cents on the issue.  #3 is a possible compromise for
>>> everyone who cares about #2.
>>
>> I think #2 is not that contentious, if we just add a "comment" or 
>> "description" instvar.  If we do that, should we call it "comment"?
>
> Why not going for a real class.
> Alex can you publish your code?

Basically we don't want to wait any longer... we started talking about 
partitioning the image over two years ago.  Assuming the real class is 
functionally similar to PI (except without the string-based category 
hacks), the resulting partitioning should be the same either way, and 
we could convert the PIs to the package objects later.  (But it would 
be nice if a real usable package class was available right now.)

So yes, we are intentionally putting some time pressure on anyone who 
wants to come up with a real package class. :-)

- Doug