[Pharo-project] 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
sounds tricky. at the very least add a checker to a menu somewhere so we can start to use it. 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. cheers Mike On Fri, Jul 30, 2010 at 11:36 AM, Stéphane Ducasse <Stephane.Ducasse@inria.fr> wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, July 31, 2010 11:19 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, July 31, 2010 11:19 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Migrate-Core-BillSchwab.1.mcz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Sunday, August 01, 2010 1:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About overlapping packages :( Ok I will have a look. My new package implementation is fast and robust now I'm just bumping into fuzzy PackageInfo semantics. Stef On Aug 1, 2010, at 5:07 PM, Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, July 31, 2010 11:19 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <Migrate-Core-BillSchwab.1.mcz>_______________________________________________ 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
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
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. 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."
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
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.
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."
On 3 August 2010 11:41, Tudor Girba <tudor.girba@gmail.com> 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 <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."
_______________________________________________ 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.
participants (6)
-
Igor Stasenko -
Michael Roberts -
Schwab,Wilhelm K -
Stéphane Ducasse -
Stéphane Ducasse
-
Tudor Girba