[Pharo-project] rpackage transition
Hi, When we started with RPackage there was a debate as to the strategy regarding the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it seems this is what we now have. The detailed plan looked as follow: --- Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackages. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones. Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations. Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. --- Now we passed Stage 1 which is great. At this point, everyone can work like before, but are encouraged to create explicit Monticello packages out of categories. Next, I would like to propose that for Pharo 3.0 we go for Stage 2 and modify slightly Monticello publishing. Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."
On 14 March 2013 08:00, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
When we started with RPackage there was a debate as to the strategy regarding the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it seems this is what we now have.
The detailed plan looked as follow:
--- Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackages. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.
Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations.
.. and rewriting a working code. Why i cannot have 1 package with 2 categories 'Foo-Core' and 'Foo-Core-Bar'? Why we need such requirement? why developer cannot choose what categories going into package? Now i will be forced to fold all classes back into single category if i want to not end up with 20 little packages (which cannot be loaded, btw , because of dependency ..) To reflect, how bad it sounds to me, let me propose different publishing order: - all classes with same first two letters in name should go to same package. Do you like it? No? Not matters.. we will force you to obey to it, starting from tomorrow.
Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. ---
Now we passed Stage 1 which is great. At this point, everyone can work like before, but are encouraged to create explicit Monticello packages out of categories. Next, I would like to propose that for Pharo 3.0 we go for Stage 2 and modify slightly Monticello publishing.
Cheers, Doru
-- www.tudorgirba.com
"Quality cannot be an afterthought."
-- Best regards, Igor Stasenko.
Hi Igor, Please, let's keep the discussion at the level of arguments. The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism. At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage. The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this. Perhaps there are other options, too. Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :). Cheers, Doru On Thu, Mar 14, 2013 at 8:26 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 March 2013 08:00, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
When we started with RPackage there was a debate as to the strategy regarding the mapping. I advocated 1-to-1 mapping of categories to RPackage, and it seems this is what we now have.
The detailed plan looked as follow:
--- Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackages. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones.
Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations.
.. and rewriting a working code. Why i cannot have 1 package with 2 categories 'Foo-Core' and 'Foo-Core-Bar'?
Why we need such requirement? why developer cannot choose what categories going into package? Now i will be forced to fold all classes back into single category if i want to not end up with 20 little packages (which cannot be loaded, btw , because of dependency ..)
To reflect, how bad it sounds to me, let me propose different publishing order: - all classes with same first two letters in name should go to same package.
Do you like it? No? Not matters.. we will force you to obey to it, starting from tomorrow.
Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. ---
Now we passed Stage 1 which is great. At this point, everyone can work like before, but are encouraged to create explicit Monticello packages out of categories. Next, I would like to propose that for Pharo 3.0 we go for Stage 2 and modify slightly Monticello publishing.
Cheers, Doru
-- www.tudorgirba.com
"Quality cannot be an afterthought."
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
On 14 mars 2013, at 11:25, Tudor Girba wrote:
- either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this.
At some point last year the plan was to do both. Ensure a 1-to-1 mapping between RPackage and MCPackages and a 1-to-1 mapping between RPackage tags and categories. Then we remove categories (and mcpackages, although it is hard to force monticello to rely on rpackage in a backward compatible way).
On 14 March 2013 11:25, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Igor,
Please, let's keep the discussion at the level of arguments.
sorry.. we had conversations about that multiple times with Stef and Marcus. And it was sounded like we came to some consensus. But your statements actually an invitation to restart from where we come from..
The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism.
At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage.
yes. I was not part of development of RPackage.. and i still don't understand why it is so hard to make it map 1:1 to MC package instead of 1:1 to category. Category is nothing.. it is thin air.. it is the arbitrary name chosen by developer which he can change at any moment. It does not influencing anything at all (except from sorting the lists in browser).. A very simple rule: when you defining new class or recategorizing it, it will be added to package which name matching the category name (or first parts of it).. Does that sounds like technically impossible to implement? newclassCategory := 'Foo-Bugz' packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] ? I simply cannot find a good justification, why instead of doing small change in single place, we want to force numerous people do a lot of changes over whole world of packages. It doesn't sounds like a smart move. Especially if there would be clear benefit.. But there's not. At least i don't see one.
The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this.
yes this was added.. so we need last bit - make tags play role of categories. and make MC directly interact with RPackage for loading/snapshotting stuff. but since we cannot make everything at once, i hope gradually we will come there.
Perhaps there are other options, too.
Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :).
From machine's perspective , a package is just a collection of objects. Machine don't needs any naming there in order to make it run. Names are meaningful only to humans. So, categories/tags is extra metainformation which should be kept by package to make sure humans can understand it. Because if going to extreme, if you strip all names away, then you turning a package into unsorted set of objects, without any means to distinguish one from another by developers..
Does that sounds like 'sound engineering'? :)
Cheers, Doru
-- Best regards, Igor Stasenko.
Can we please first release 2.0 before we waste all our energy in useless discussions? On Mar 14, 2013, at 1:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 March 2013 11:25, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Igor,
Please, let's keep the discussion at the level of arguments.
sorry.. we had conversations about that multiple times with Stef and Marcus. And it was sounded like we came to some consensus. But your statements actually an invitation to restart from where we come from..
The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism.
At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage.
yes. I was not part of development of RPackage.. and i still don't understand why it is so hard to make it map 1:1 to MC package instead of 1:1 to category.
Category is nothing.. it is thin air.. it is the arbitrary name chosen by developer which he can change at any moment. It does not influencing anything at all (except from sorting the lists in browser)..
A very simple rule: when you defining new class or recategorizing it, it will be added to package which name matching the category name (or first parts of it).. Does that sounds like technically impossible to implement?
newclassCategory := 'Foo-Bugz' packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] ?
I simply cannot find a good justification, why instead of doing small change in single place, we want to force numerous people do a lot of changes over whole world of packages. It doesn't sounds like a smart move. Especially if there would be clear benefit.. But there's not. At least i don't see one.
The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this.
yes this was added.. so we need last bit - make tags play role of categories. and make MC directly interact with RPackage for loading/snapshotting stuff.
but since we cannot make everything at once, i hope gradually we will come there.
Perhaps there are other options, too.
Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :).
From machine's perspective , a package is just a collection of objects. Machine don't needs any naming there in order to make it run. Names are meaningful only to humans. So, categories/tags is extra metainformation which should be kept by package to make sure humans can understand it. Because if going to extreme, if you strip all names away, then you turning a package into unsorted set of objects, without any means to distinguish one from another by developers..
Does that sounds like 'sound engineering'? :)
Cheers, Doru
-- Best regards, Igor Stasenko.
Hi, I am sorry to have wasted your time. Cheers, Doru On Thu, Mar 14, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
Can we please first release 2.0 before we waste all our energy in useless discussions?
On Mar 14, 2013, at 1:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 March 2013 11:25, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Igor,
Please, let's keep the discussion at the level of arguments.
sorry.. we had conversations about that multiple times with Stef and Marcus. And it was sounded like we came to some consensus. But your statements actually an invitation to restart from where we come from..
The original reasons for developing RPackage were: - to offer a first class package object in the image and to remove the category-string-based-solution, and - to get rid of Monticello-magic-mapping, and potentially offer the option of adding tags as an orthogonal mechanism.
At this moment, we have RPackage mapped one-to-one to categories, but the core implementation still relies on categories. So, at the very least, we should find a way to remove categories and directly rely on RPackage.
yes. I was not part of development of RPackage.. and i still don't understand why it is so hard to make it map 1:1 to MC package instead of 1:1 to category.
Category is nothing.. it is thin air.. it is the arbitrary name chosen by developer which he can change at any moment. It does not influencing anything at all (except from sorting the lists in browser)..
A very simple rule: when you defining new class or recategorizing it, it will be added to package which name matching the category name (or first parts of it).. Does that sounds like technically impossible to implement?
newclassCategory := 'Foo-Bugz' packageToAddTo := packages detect:[:ea | newclassCategory beginsWith: ea name ] ?
I simply cannot find a good justification, why instead of doing small change in single place, we want to force numerous people do a lot of changes over whole world of packages. It doesn't sounds like a smart move. Especially if there would be clear benefit.. But there's not. At least i don't see one.
The Monticello mapping is there only for historical reasons. To eliminate it we need a strategy. For this, I see two options: - either we go with simply removing categories altogether and just relying on RPackages with 1-to-1 mappings to Monticello packages, - we introduce another mechanism (such as tags) that allows us to map categories on this.
yes this was added.. so we need last bit - make tags play role of categories. and make MC directly interact with RPackage for loading/snapshotting stuff.
but since we cannot make everything at once, i hope gradually we will come there.
Perhaps there are other options, too.
Btw, I thought that in Pharo, backward compatibility is secondary to sound engineering :).
From machine's perspective , a package is just a collection of objects. Machine don't needs any naming there in order to make it run. Names are meaningful only to humans. So, categories/tags is extra metainformation which should be kept by package to make sure humans can understand it. Because if going to extreme, if you strip all names away, then you turning a package into unsorted set of objects, without any means to distinguish one from another by developers..
Does that sounds like 'sound engineering'? :)
Cheers, Doru
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
participants (4)
-
Camille Teruel -
Igor Stasenko -
Marcus Denker -
Tudor Girba