SM future version

Anthony Hannan ajh18 at cornell.edu
Fri Nov 22 22:26:45 UTC 2002


Proceeding incrementally is fine, but I still think we need to discuss
and decide which final "elegant" package design we want.  Then we will
have a goal that will provide a road map for the incremental changes,
and avoid incremental changes that may later be harder to adapt to the
goal.

My point in my last message about being object-oriented is that "meta"
data about packages and the packages themselves should be merged into
single package objects.  Just having some "meta" data available for query
is not good enough.  What if I want to find all packages that implement
or send a particular selector.

I understand the nice thing about separate "meta" data is that it allows
just the "meta" data to be loaded without the rest of the package.  But
this is a problem that can be better solved with an object database.  It
could load just the package objects without loading its classes until
they are needed.  And object database is also beneficial in other areas
as well.  So, we might better utilize our efforts in pursuing a general
object database solution instead of a specific package files solution.

In short, I think the current package movement is trying to solve two
separate problems:
	(1) Organizing versions of classes and class extensions, and
	(2) Loading only what is needed.

I think using two separate solutions is the best answer:
	(1) PIE or something like it, and
	(2) An object database (a distibuted one preferrably)

Colin Putney <cputney at whistler.com> wrote:
> The hard part is actually carving up the tangled mass 
> of existing code that's currently in the image and free floating 
> changesets.

I agree.  Traits will help a lot with this.  Once code is separated into
traits, it will be possible to trace the code and extract out only the
traits needed.  This can be done on classes today, but you will get more
than you need.  There is an algorithm for inferring semi-descent traits
from classes based on selector names and who implements them.  I
presented it in my "Class Dependencies" email last weekend.

Cheers,
Anthony



More information about the Squeak-dev mailing list