Potentially, user could state explicitly to which package belongs given class/method, ignoring all naming stuff. An alternative approach is to disentangle the category name from package name and matching logic. Instead of ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Kernel-Objects' change it to: ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Objects' package: 'Kernel' or as separate doit: !ProtoObject subclass: #Object instanceVariableNames: '' classVariableNames: 'DependentsFields' poolDictionaries: '' category: 'Objects'.! !Object package: 'Kernel'.! On 2 August 2010 10:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 1, 2010, at 10:40 PM, Tudor Girba wrote:
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.
I know this is why I'm doing it slowly and with some pain... :)
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.