About overlapping packages :(

> Hi
>
> I have worked on the integration of the new package implementation and its synchronisation with MC/PackageInfo.
> Now I have the following problem:
>
> Scenario 1:
>        the user have created a package Foo which contains several classes, some like FooObject
>        in the category Foo-Core, others in category Foo-Others.
>        Now if he creates a package Foo-Core, Foo-Core should contain the classes
>        having Foo-Core as category.
>
>        I have a problem with PackageInfo semantics since here packages Foo and Foo-Core could contain
>        FooObject.
>
> Scenario 2:
>        the user have created a class in the category Foo-Core, and after created a package only named Foo.
>        The classes in category Foo-Core should be added to Foo. But some other packages and categories starting with Foo may exist.
>
>
> Now in the new implementation, classes cannot be two packages at the same time. So I will be forced
> to implement a checker making sure that there is no such situation and also that we should remove
> first the Foo package and then create two package Foo-Core and Foo-Others.
> What do you think?
>
> May be such a checker should be hooked into MC right now so we detect anyway such bad situations.
>
> For the moment I'm fighting within events and announcements to make sure that I could potentially
> keep the new implementation of Package and PackageOrganizer in sync with PackageInfo but this is not that simple.
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Stef,
>
> Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo.  One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error.  The truth is that it is not a big deal: save the image and figure it out after you get some coffee.   However, it sure seems awful the first few times the system refuses to save a package.
>
> Dolphin uses concrete packages; classes, methods and other objects belong to a package.  Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere.  Packages are explicitly created by the user and then are separately populated.
>
> I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages.  Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier.  However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello.  I responded by "porting" a tool called Migrate that I wrote early on for Dolphin.  Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each.  Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo.
>
> Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons.  First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else.  Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are.  In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image.
>
> Perhaps the place to start is to have a quick look and to let me know if you have any questions.
>
> Bill
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
> Sent: Saturday, July 31, 2010 11:19 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] About overlapping packages :(
>
>> sounds tricky. at the very least add a checker to a menu somewhere so
>> we can start to use it.
>
> I will do that.
>
>> You wouldn't need to that deeply integrate it
>> in the first instance...
>>
>> do you need to match the existing semantics exactly? I don't think
>> it's good that we can get into these situations. Perhaps we should
>> prevent them being able to be created in the first place, rather than
>> deal with them once they overlap.
>
> It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created)
> , but will have to start delete the top package.
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> <Migrate-Core-BillSchwab.1.mcz>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Stef,
>
> Coming from Dolphin, I have been surprised at how few packaging problems I (appear?) to have had in Pharo.  One of the great terrors<g> that enters the life of each Dolphin newbie is the dreaded "cyclic dependencies" error.  The truth is that it is not a big deal: save the image and figure it out after you get some coffee.   However, it sure seems awful the first few times the system refuses to save a package.
>
> Dolphin uses concrete packages; classes, methods and other objects belong to a package.  Non-class objects (methods, view resources) by default belong to the same package as the associated class, but they can be placed elsewhere.  Packages are explicitly created by the user and then are separately populated.
>
> I was generally shocked at how much work both Dolphin and Pharo users were willing to do in saving and loading packages.  Over time, Dolphin became fairly adept at loading prerequisite packages, so things got easier.  However, the readers here (for whom I have great respect) mystify me - or I am missing something about Monticello.  I responded by "porting" a tool called Migrate that I wrote early on for Dolphin.  Dolphin's package manager was fussy about loading things in the correct order, and I had no patience for loading 100+ packages with menu commands for each.  Like I said, it improve over time to make Migrate less important in Dolphin, but something like it was essential to me in Pharo.
>
> Attached is a .mcz for Migrate-Core, relevant perhaps for two reasons.  First, the fact that I exploit the ability to make a package called Migrate and then dash off a Migrate-Core that (hopefully) has just what I want to make public and nothing else.  Second, it might give you some ideas about what a package system should do. My code is managed by a class called GatorAid that is derived from Migrate, and other users would presumably do the same thing: subclass, override a couple of methods, and follow the instructions (mostly in the Migrate class comment and some method comments), such as they are.  In short, it helps look for code that I wrote and have not yet claimed ownership by telling Migrate I want to save it; it makes saving all packages I have asked it to save a one-step operation; it helps with building a new image.
>
> Perhaps the place to start is to have a quick look and to let me know if you have any questions.
>
> Bill
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
> Sent: Saturday, July 31, 2010 11:19 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] About overlapping packages :(
>
>> sounds tricky. at the very least add a checker to a menu somewhere so
>> we can start to use it.
>
> I will do that.
>
>> You wouldn't need to that deeply integrate it
>> in the first instance...
>>
>> do you need to match the existing semantics exactly? I don't think
>> it's good that we can get into these situations. Perhaps we should
>> prevent them being able to be created in the first place, rather than
>> deal with them once they overlap.
>
> It will change the flow: we will not be able to create a new subpackage Foo-Core (if Foo is already created)
> , but will have to start delete the top package.
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> <Migrate-Core-BillSchwab.1.mcz>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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
>> [hidden email]
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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 <[hidden email]>  
> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>
>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>