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
