Yes, that would be an option. The problem with this is that you have to change everything from the beginning. The route of first mirroring the categories is smoother because first you can focus on the tools and when everything works well, you can remove categories with a construction that goes along the lines you suggest. Cheers, Doru On 3 Aug 2010, at 04:10, Igor Stasenko wrote:
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Be rather willing to give than demanding to get."