About RPackage
Locked
 
|
Hi cyrille/doru and others.
I do not understand why RPackage organizer packages contains System? In fact all the categories are mapped to packages and I wonder why. I imagine that this is to avoid to have mostSpecific* logic of packageInfo, but it means that in such a case we should merge categories to get back the package we have right now else we will end up with loading/saving problems. Stef |
|
|
Hi Stef,
This was the decisions that two of us (I mean me and you) took :). Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. Cheers, Doru On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: > Hi cyrille/doru and others. > > I do not understand why > RPackage organizer packages contains System? > > In fact all the categories are mapped to packages and I wonder why. > I imagine that this is to avoid to have mostSpecific* logic of packageInfo, > but it means that in such a case we should merge categories to get back the package we have right now > else we will end up with loading/saving problems. > > > Stef -- www.tudorgirba.com "Presenting is storytelling." |
|
|
In reply to this post by Stéphane Ducasse
Another point
RPackage>>named: aString | newPackage | newPackage := self new name: aString ;yourself. "self organizer registerPackage: newPackage." ^ newPackage does not register the package and this looks suspicion to me. In addition I do not remember the exact logic but the pattern with PackageInfo is that PackageInfo named: #foo creates the package if it does exist PackageInfo class>>named: aString ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] So do you remember because it may be better to have the same creation protocol. Stef > Hi cyrille/doru and others. > > I do not understand why > RPackage organizer packages contains System? > > In fact all the categories are mapped to packages and I wonder why. > I imagine that this is to avoid to have mostSpecific* logic of packageInfo, > but it means that in such a case we should merge categories to get back the package we have right now > else we will end up with loading/saving problems. > > > Stef |
|
|
This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :).
Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. Cheers, Doru On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: > Another point > > RPackage>>named: aString > > | newPackage | > newPackage := self new name: aString ;yourself. > "self organizer registerPackage: newPackage." > ^ newPackage > > does not register the package and this looks suspicion to me. > > > In addition I do not remember the exact logic but the pattern with PackageInfo is that > > PackageInfo named: #foo creates the package if it does exist > > PackageInfo class>>named: aString > ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] > > So do you remember because it may be better to have the same creation protocol. > > Stef > > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- www.tudorgirba.com "Be rather willing to give than demanding to get." |
|
|
In reply to this post by Tudor Girba
On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote: > Hi Stef, > > This was the decisions that two of us (I mean me and you) took :). Yes I remember :) > Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. > > The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. a path is probably to evaluate the current categories and merged/reorganize them to look like packages. Of course some people will cry but this is the way to go. > The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. > > Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. yes > > Cheers, > Doru > > > > On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > |
|
|
In reply to this post by Tudor Girba
On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote: > This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). Ok I do not remember the protocol. we should ask the PackageOrganizer to create a package? or just to register it. I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. So in the PackageInfo logic there are two points; - registration - query/creation I have no problem to discard - query/creation So to which of these two aspects are you referring to. Stef > > Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. > > Cheers, > Doru > > > On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: > >> Another point >> >> RPackage>>named: aString >> >> | newPackage | >> newPackage := self new name: aString ;yourself. >> "self organizer registerPackage: newPackage." >> ^ newPackage >> >> does not register the package and this looks suspicion to me. >> >> >> In addition I do not remember the exact logic but the pattern with PackageInfo is that >> >> PackageInfo named: #foo creates the package if it does exist >> >> PackageInfo class>>named: aString >> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >> >> So do you remember because it may be better to have the same creation protocol. >> >> Stef >> >> >>> Hi cyrille/doru and others. >>> >>> I do not understand why >>> RPackage organizer packages contains System? >>> >>> In fact all the categories are mapped to packages and I wonder why. >>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>> but it means that in such a case we should merge categories to get back the package we have right now >>> else we will end up with loading/saving problems. >>> >>> >>> Stef >> >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > |
|
|
Hi,
On 2 Mar 2011, at 09:12, Stéphane Ducasse wrote: > > On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote: > >> This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :). > > Ok I do not remember the protocol. > we should ask the PackageOrganizer to create a package? > or just to register it. The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package. If you want to ensure a package, you should use (I do not like the name :)): RPackageOrganizer>>registerPackageNamed: aSymbol ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] You can get to the default organizer via "RPackage organizer". So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. > I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. > So in the PackageInfo logic there are two points; > - registration > - query/creation > > I have no problem to discard - query/creation > So to which of these two aspects are you referring to. In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: named: aString ^ RPackage organizer registerPackageNamed: aString Cheers, Doru > Stef > >> >> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. >> >> Cheers, >> Doru >> >> >> On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: >> >>> Another point >>> >>> RPackage>>named: aString >>> >>> | newPackage | >>> newPackage := self new name: aString ;yourself. >>> "self organizer registerPackage: newPackage." >>> ^ newPackage >>> >>> does not register the package and this looks suspicion to me. >>> >>> >>> In addition I do not remember the exact logic but the pattern with PackageInfo is that >>> >>> PackageInfo named: #foo creates the package if it does exist >>> >>> PackageInfo class>>named: aString >>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >>> >>> So do you remember because it may be better to have the same creation protocol. >>> >>> Stef >>> >>> >>>> Hi cyrille/doru and others. >>>> >>>> I do not understand why >>>> RPackage organizer packages contains System? >>>> >>>> In fact all the categories are mapped to packages and I wonder why. >>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>>> but it means that in such a case we should merge categories to get back the package we have right now >>>> else we will end up with loading/saving problems. >>>> >>>> >>>> Stef >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> > > -- www.tudorgirba.com "Being happy is a matter of choice." |
|
|
>>
>> Ok I do not remember the protocol. >> we should ask the PackageOrganizer to create a package? >> or just to register it. > > The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package. > > If you want to ensure a package, you should use (I do not like the name :)): yes this is more than registering. this is ensurePackageNamed: > RPackageOrganizer>>registerPackageNamed: aSymbol > ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] > > You can get to the default organizer via "RPackage organizer". > > So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. > >> I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. >> So in the PackageInfo logic there are two points; >> - registration >> - query/creation >> >> I have no problem to discard - query/creation >> So to which of these two aspects are you referring to. > > In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). > > What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: > > named: aString > ^ RPackage organizer registerPackageNamed: aString Yes good idea. > > > Cheers, > Doru > > > >> Stef >> >>> >>> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. >>> >>> Cheers, >>> Doru >>> >>> >>> On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote: >>> >>>> Another point >>>> >>>> RPackage>>named: aString >>>> >>>> | newPackage | >>>> newPackage := self new name: aString ;yourself. >>>> "self organizer registerPackage: newPackage." >>>> ^ newPackage >>>> >>>> does not register the package and this looks suspicion to me. >>>> >>>> >>>> In addition I do not remember the exact logic but the pattern with PackageInfo is that >>>> >>>> PackageInfo named: #foo creates the package if it does exist >>>> >>>> PackageInfo class>>named: aString >>>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >>>> >>>> So do you remember because it may be better to have the same creation protocol. >>>> >>>> Stef >>>> >>>> >>>>> Hi cyrille/doru and others. >>>>> >>>>> I do not understand why >>>>> RPackage organizer packages contains System? >>>>> >>>>> In fact all the categories are mapped to packages and I wonder why. >>>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>>>> but it means that in such a case we should merge categories to get back the package we have right now >>>>> else we will end up with loading/saving problems. >>>>> >>>>> >>>>> Stef >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > > |
|
|
In reply to this post by Tudor Girba
On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote: > Hi Stef, > > This was the decisions that two of us (I mean me and you) took :). > > Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf. We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good) > The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. > > The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages > > Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. > > Cheers, > Doru > > > > On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > |
|
|
>> This was the decisions that two of us (I mean me and you) took :).
>> >> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. > > > Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf. > We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good) PackageInfo and RPackage cannot coexist? In any case, it will not be a problem for me to update all my config with this new schema. Alexandre > >> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. >> >> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. > > > the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages > >> >> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. >> >> Cheers, >> Doru >> >> >> >> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: >> >>> Hi cyrille/doru and others. >>> >>> I do not understand why >>> RPackage organizer packages contains System? >>> >>> In fact all the categories are mapped to packages and I wonder why. >>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>> but it means that in such a case we should merge categories to get back the package we have right now >>> else we will end up with loading/saving problems. >>> >>> >>> Stef >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On Mar 3, 2011, at 2:01 52PM, Alexandre Bergel wrote:
It's been awhile since I looked at RPacakge, but... Not if you want a clean transition, you either use one, or the other. Trying to maintain the package structure in two systems at a time can only lead to trouble, especially when they do not have the same constraints. (RPackage is not tied/derived from to category classification like PackageInfo is)
I'm not sure what you mean by configs. The contents of a Monticello package is simply a collection of definitions, and will stay the same. The browser will probably need updating though, since extensions no longer necessarily have to be in a *packagename category . Loading a Monticello package stored from an RPackage-based system into a system still using PackageInfo might cause false dirties , for the same reason. As long as there is no package browser as standard (like there is in VW), and people still specify extensions by using * categories in a system browser, that's not likely to be a big issue though. RPackage does make it much easier to create a performant package browser though :) Cheers, Henry |
|
|
In reply to this post by abergel
Same for me.
Lets avoid make's issues with tabulator in unix, now that are few users. Cheers El jue, 03-03-2011 a las 10:01 -0300, Alexandre Bergel escribió: > >> This was the decisions that two of us (I mean me and you) took :). > >> > >> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. > > > > > > Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf. > > We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good) > > PackageInfo and RPackage cannot coexist? > > In any case, it will not be a problem for me to update all my config with this new schema. > > Alexandre > > > > > > >> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. > >> > >> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. > > > > > > the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages > > > >> > >> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote: > >> > >>> Hi cyrille/doru and others. > >>> > >>> I do not understand why > >>> RPackage organizer packages contains System? > >>> > >>> In fact all the categories are mapped to packages and I wonder why. > >>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, > >>> but it means that in such a case we should merge categories to get back the package we have right now > >>> else we will end up with loading/saving problems. > >>> > >>> > >>> Stef > >> > >> -- > >> www.tudorgirba.com > >> > >> "Presenting is storytelling." > >> > >> > > > > > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
|
|
In reply to this post by Henrik Sperre Johansen
>> In any case, it will not be a problem for me to update all my config with this new schema.
> I'm not sure what you mean by configs. > The contents of a Monticello package is simply a collection of definitions, and will stay the same. > The browser will probably need updating though, since extensions no longer necessarily have to be in a *packagename category . > Loading a Monticello package stored from an RPackage-based system into a system still using PackageInfo might cause false dirties , for the same reason. > As long as there is no package browser as standard (like there is in VW), and people still specify extensions by using * categories in a system browser, that's not likely to be a big issue though. RPackage does make it much easier to create a performant package browser though :) For example, currently, ConfigurationOfMetacelloBrowser loads one package, MetacelloBrowser. But the package itself has many categories (-Core, -Test, ...). So, if each class category is a package, then I will have to update the category. But I am for it! The cost of updating configurations is much less than what we are all spending because PackageInfo (just think how many times you have press '+Package' in the Monticello browser). Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Henrik Sperre Johansen
henrik and others
We are making sure that the IDE generates information so that the new organizer deals well with *notation even if internally he does not use that. The problem is that in PackageInfo Kernel-Text Kernel-Foo are both in Kernel package. Now in RPackage Kernel-Text Kernel-Foo are two different packages and this is why I'm saying that we should find a path because we will break existing configurationOf.... Stef |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |