Monticello, SM2, BFAV in 3.7alpha
Avi Bryant
avi at beta4.com
Tue Jan 27 00:19:39 UTC 2004
On Jan 26, 2004, at 3:35 PM, Michael Rueger wrote:
> I may be the lonely kid on the block here, but I'm against it on
> principle. I don't use the Monticello for a variety of reasons, but
> besides that I don't want *any* (can I double bold this?) packaging
> system in the basic system.
> Packaging systems have the tendency to viral themselves into all
> aspects of the core system and once they are there, nobody even has
> the chance to come up with a different approach.
>
> The total and utterly failure of the module system, from which we had
> to back out as we couldn't remove it any more, taught us a lesson,
> please let's remember it.
>
> I'm not saying that Monticello is not a usable (and hopefully at some
> point stable) system, but packaging should not be built-in. Period.
>
> I like the SM approach, as it does not enforce a particular packaging
> approach, but rather allows people to post their code in whatever
> loadable format they want.
If I can ramble about this for a bit - I guess there are at least three
issues here for me:
- "Package definition" (grouping classes and methods within the image)
is not the same as "package management" (which includes mechanisms for
loading/storing/versioning packages)
- "In the Basic image" (loaded by default into the image people
download) is not the same as "part of the core system" (it's difficult
or impossible to have a useful image without it because so much depends
on it)
- Putting interfaces in the core is not the same as putting
implementations in the core
I agree with you in that I would argue very strongly against having any
particular package management implementation being part of the core
system. The design space is just too large, and the options too
varied, for it to make sense to commit ourselves strongly to one
system. As you say, SM has exactly the right approach here.
I would argue almost as strongly that we *should* have a package
definition interface as part of the core. That is, I think it would be
useful to have a standard Package interface (or, if you prefer, call it
Categorization) that various system tools like the Browser can depend
on. Nothing fancy, just a way to tell what discrete groups of code
exist in the image. SystemOrganizer is one possible implementation of
this, that the tools all currently know about and use. PackageInfo is
another possible implementation, basically just a subtle refinement of
SystemOrganizer. We may have better implementations in the future.
But this is something that most tools benefit from (indeed, are
benefitting from, in the form of SystemOrganizer), and it's something
that's easy to build an abstract interface around.
The question at hand is whether to put a particular package management
implementation (Monticello) into the Basic image. I don't actually
think this would be a problem, for this reason: as long as we have a
good Package abstraction in the core, people building tools will depend
on that rather than on Monticello, which would itself be just another
client of the Package abstraction (this was of course the point of
separating out PackageInfo). Other package management systems could
easily live side by side with it and use the same Package objects, so
there shouldn't be any viral effect. By the same logic, however, I
don't think it's crucial that we put it into Basic - since nothing
should be depending on it, it should always be trivial for a user to
just load it with a single click from the Package Loader when they want
it (or load it on demand from an item in the world menu, or whatever).
</ramble>
Avi
More information about the Squeak-dev
mailing list
|