On 3 August 2010 11:41, Tudor Girba <[email protected]> wrote: > 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. >
Sure thing. It needs to be done cleverly. I am just thinking that at some point, this should be separated, so it worth to make changes in current codebase by taking this into acccount. > 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 <[email protected]> >> 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 >>>>> [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 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
