[squeak-dev] Re: Packages, Packages, Packages
Andreas Raab
andreas.raab at gmx.de
Sat Dec 12 07:43:21 UTC 2009
Miguel Cobá wrote:
> Maybe more attention to the real uses of the technology
> outside the "core" squeak is needed here.
> Since some months ago, Dale Henrichs has made available Metacello
> that doesn't tries to "fix" monticello, but to build on top of the
> limitations of it by treating monticello as what does better:
> to load a single version of a given package in the image.
> Then it adds the apropriate "package" dependencies in
> a higher level. No need to feature creep monticello but use
> it as a sound base for solving the issues you mentioned.
I do not understand which problem domain Metacello is addressing and
how. If you have more information, this would be very welcome.
>> Since none of the solutions above currently fits all the requirements we'll
>> have to fix some. That could mean adding dependencies to SqueakMap; it could
>> mean giving Universes a reasonable UI; it could mean fixing dependencies in
>> Monticello. I really don't care either way but I think we'll have to figure
>> something out here. Is anyone out there interested in or perhaps even
>> working on addressing any of these issues?
>
> Please, let behind that "squeak for all" mentality. The right tool for
> the right job.
> One tool (squeak or any other) can't solve all the problems.
I'm not claiming it can. I'm laying out a couple of issues that we need
to address, and list the current options as far as I understand them.
The only thing I'm strongly against is to end up with another dependency
on a tool that hasn't been written yet and that by the end of the day
will the job just as incomplete as the alternatives.
>> The second big issue is how we deal with "core" vs. "extended" packages in
>> Squeak. As we move towards a smaller kernel, we should know which packages
>> are core and which ones are not. And when we remove packages that are
>> currently part of the image, we need a place to put them.
>
> Discussend long time ago in Pharo. Some useful ideas can be gathered
> from there, even if the project name produce some bad feelings.
Can you summarize the results of that discussion?
> So the question is, has ever been considered to simply build the bridge between
> communities and to use the PharoCore image as the base for Squeak?
This wouldn't work for the same reasons that it wouldn't work to use a
Squeak-trunk image as the basis for Pharo. You should propose that at
some point just to see what kind of reaction you get ;-)
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|