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
|