Partitioning the image (was Re: Shrinking sucks!)

Doug Way dway at mailcan.com
Sun Feb 13 07:16:44 UTC 2005


On Feb 12, 2005, at 4:32 PM, Lex Spoon wrote:

> It is nice in principle, to reuse code whenever possible.  However, we
> are talking about small amounts of code, that are going to be at the
> center of our processes.  Surely we should do this right.  I think it 
> is
> a very bad idea, that everywhere we see name+author+comment, that we
> think we have to use SqueakMap for it.  We have the option here of
> adding a few variables to PackageInfo and continuing on our merry way.
> Let's please not stop here and argue that there's a theoretical better
> way that we could instead use.

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

I think there is some agreement that we should add a comment (or 
description) variable to PackageInfo.  A class has a comment, a method 
can have a comment, a package should probably have a comment too.  
(Perhaps Avi was hinting at disagreement by saying that you can 
subclass PackageInfo, then you could use the class comment in the 
subclass.  But I still think PI instances should be able to have a 
comment too, since we allow PI instances.)

I kind of think of SqueakMap as the interface to the outside world of 
packages.  Some of the meta-data associated with packages is mostly 
"outside world" related, such as the URL, whether it's "published", 
which SM version it is... these are probably not as essential for a 
simple in-image PackageInfo, so they could stay in SMPackage.  "Author" 
is kind of a borderline case... method timestamps in the image have 
author initials, although classes in the image don't keep track of 
their authors.  I guess I'm okay with most metadata being in SMPackage 
for now.

> (snip)
>
> So, my proposal is:
>
> 	1. Move ahead with PackageInfo.

Yes.

> 	2. Add some minor descriptive info to PackageInfo, like "description",
> and maybe a url for more info.  It would be great for these to be 
> there.
>  The description should be a Text, ideally, just like class comments.

I think adding a single comment/description instvar is a good idea.  
Mmm, a url seems like something relating to the outside world which 
could be handled by the corresponding SMPackage instance.

> 	3. Add some sort of variable, which optionally refers to a SqueakMap
> package corresponding to that PackageInfo.  I defer to Goran for what
> kind of info should go there, but the idea is, so long as the tools 
> know
> which PackageInfo goes with which SqueakMap package, the tools can do
> all the same smart things they could do if PackageInfo were the *same*
> as a SqueakMap package.

I think the SMPackage actually points to the PackageInfo instance right 
now (if it's a PI-based SMPackage).  So, mm, I think every PackageInfo 
should be able to look up its corresponding SMPackage.  Goran can 
confirm.  Maybe that needs  a bit of thought as to how they will be 
looked up.

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

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.

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"?

- Doug




More information about the Squeak-dev mailing list