Hi Stef,
I would go for first mirroring categories. Like this, Monticello would
still work as expected, and we can just focus on improving the image
based tools/concepts.
Cheers,
Doru
On 1 Aug 2010, at 22:02, Stéphane Ducasse wrote:
Stef,
Are you perhaps running into problems with mapping category names
to packages? The Dolphin approach to that is to avoid the topic:
just present a list of packages and make the user pick one, after
which the class/method/etc. is packaged. The resulting package
system might then suffer the indignity of cyclic prerequisites, but
there are ways to help the user fix that. I am not saying it is
the correct solution (nor suggesting that it is not) - just
reporting what Object Arts did. They got so many things *really*
right that I default to trusting them.
This is what my implementation does. No magic matching. Just a list
of classes and methods.
Now if I do not support the * convention of packageinfo it means
that we will not be able to load and save
packages in a compatible form. We could do that and it would save me
a lot of work. But people have to agree and understand the
consequences. Of course we could do a MCPackageInfor specific loader
that loads and convert MC packages.
But this means that the packages will not be able to be used in
Squeak.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
