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.duca...@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."
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
