[Pharo-project] need your attention: Package
Hi guys we need to think about package: right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted. - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories. Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching. So if you have suggestion please talk now. Stef
On 18 March 2011 21:56, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead.
Cool!
RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because:     - Rpackage does not rely on category tagging matching.     - It is simpler to have a mapping from current categories to packages     - Now it means that we could load a package in the system and it would be turned into several RPackages     so this means that configuration would have to be adapted.
    - marcus was suggesting me to create a package with the same contents as the one of loaded by MC.     and to have tags to only represent categories.
Is this a conscious decision to have an unique package per each category name, or just a technical limitation? I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
Now my time is short so I will     - probably not implement tags     - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange     code.     - check the MC dependency on method category conventions, because some logic is not defined in the right place     like overrides in the MC tools and not in the PackageInfo     - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to     associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames     and change the packages accordingly).     - we should not rely on most-specific-category kind of pattern matching.
As i suggested, we should not rely on category naming in new packages at all. I think we could create an importer which using a legacy logic of making classes belong to some package based on their category name. In future that should be removed.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.
Is this a conscious decision to have an unique package per each category name, or just a technical limitation?
RPAckage has nothing to do with category matching: a package is a list of classes and methods. Now the problem is simply the following: you have a MC package FOO it contains FOO-Cat1 you load it: ok the loader could create RPAckage Foo and put FOO classes and Foo-Cat Classes in it Now you create a new category FOO-z what should I do add it to FOO create a package Foo-z We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
As i suggested, we should not rely on category naming in new packages at all. I think we could create an importer which using a legacy logic of making classes belong to some package based on their category name.
Yes but this is a pain. :)
In future that should be removed.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.
So I will check to see what can be done but it looks painful. Stef
Is this a conscious decision to have an unique package per each category name, or just a technical limitation?
RPAckage has nothing to do with category matching: a package is a list of classes and methods.
Now the problem is simply the following:
you have a MC package FOO it contains FOO-Cat1
you load it: ok the loader could create RPAckage Foo and put FOO classes and Foo-Cat Classes in it
Now you create a new category FOO-z what should I do add it to FOO create a package Foo-z
We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
As i suggested, we should not rely on category naming in new packages at all. I think we could create an importer which using a legacy logic of making classes belong to some package based on their category name.
Yes but this is a pain. :)
In future that should be removed.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.
On 19 March 2011 08:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Is this a conscious decision to have an unique package per each category name, or just a technical limitation?
RPAckage has nothing to do with category matching: a package is a list of classes and methods.
Now the problem is simply the following:
    you have a MC package FOO     it contains FOO-Cat1
    you load it: ok the loader could create         RPAckage Foo             and put FOO classes and Foo-Cat Classes in it
    Now you create a new category         FOO-z what should I do         add it to FOO         create a package Foo-z
We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.
No. The process should be different: You marking an active package (in same way as currently we having an active changeset). Then anything you do (any classes or methods you creating) is going straightly to that package. Now, what to do if you hacking around or do refactoring over multiple classes in multiple packages: - you can say that for the time of your hacking session a methods you changing/adding should belong to same packages as their classes (instead of adding methods to single active package as extensions). This should be default behavior.
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
-- Best regards, Igor Stasenko AKA sig.
On 19 March 2011 15:53, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 March 2011 08:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Is this a conscious decision to have an unique package per each category name, or just a technical limitation?
RPAckage has nothing to do with category matching: a package is a list of classes and methods.
Now the problem is simply the following:
    you have a MC package FOO     it contains FOO-Cat1
    you load it: ok the loader could create         RPAckage Foo             and put FOO classes and Foo-Cat Classes in it
    Now you create a new category         FOO-z what should I do         add it to FOO         create a package Foo-z
We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.
No. The process should be different:
You marking an active package (in same way as currently we having an active changeset). Then anything you do (any classes or methods you creating) is going straightly to that package.
Now, what to do if you hacking around or do refactoring over multiple classes in multiple packages: Â - you can say that for the time of your hacking session a methods you changing/adding should belong to same packages as their classes (instead of adding methods to single active package as extensions). This should be default behavior.
Or, since you doing new environment-tied browser, you can say to single browser instance: please stick with this package, and for another instance - stick with another. Then anything you do in browser goes to these package(s).
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
The problem is how do we handle packages when people do not use nautilus Stef On Mar 19, 2011, at 3:55 PM, Igor Stasenko wrote:
On 19 March 2011 15:53, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 March 2011 08:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Is this a conscious decision to have an unique package per each category name, or just a technical limitation?
RPAckage has nothing to do with category matching: a package is a list of classes and methods.
Now the problem is simply the following:
you have a MC package FOO it contains FOO-Cat1
you load it: ok the loader could create RPAckage Foo and put FOO classes and Foo-Cat Classes in it
Now you create a new category FOO-z what should I do add it to FOO create a package Foo-z
We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages.
No. The process should be different:
You marking an active package (in same way as currently we having an active changeset). Then anything you do (any classes or methods you creating) is going straightly to that package.
Now, what to do if you hacking around or do refactoring over multiple classes in multiple packages: - you can say that for the time of your hacking session a methods you changing/adding should belong to same packages as their classes (instead of adding methods to single active package as extensions). This should be default behavior.
Or, since you doing new environment-tied browser, you can say to single browser instance: please stick with this package, and for another instance - stick with another. Then anything you do in browser goes to these package(s).
I'd prefer to have a package which can allow an arbitrary category names in future. It may be that tools like browser are not prepared for that.. but not an internal information of package. To my thinking , classes which belong to package could have any category names.. Names should not mean anything.. it is just for humans.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
I understand that the best way to prepare an application for RPackage is to make sure we have turned each category as a package. Is there something else? Class extension maybe a problem you said. Alexandre Le 18 mars 2011 à 16:56, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
On Mar 19, 2011, at 2:31 AM, Alexandre Bergel wrote:
I understand that the best way to prepare an application for RPackage is to make sure we have turned each category as a package. Is there something else? Class extension maybe a problem you said.
Not really. I'm looking now at package creation because may be I could create a package Foo (if MC says if even if category are Foo-bla) now the problem is that if somebody creates a package Foo-z then I would like to avoid to have to check all the packages names and do string matching on their category. Stef
Alexandre
Le 18 mars 2011 à 16:56, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
Stef, I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... Dale On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... But maybe it's easier (or nicer) to replace everything together... :P Guille On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
I have no idea how Rpackage done internally but i think it should be orthogonal to MC. You can implement import/export layers between MC and RPackage and make it follow any rules you want (current ones), but internal organization can be completely different. On 19 March 2011 19:17, Guillermo Polito <guillermopolito@gmail.com> wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo  that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because:    - Rpackage does not rely on category tagging matching.    - It is simpler to have a mapping from current categories to packages    - Now it means that we could load a package in the system and it would be turned into several RPackages    so this means that configuration would have to be adapted.
   - marcus was suggesting me to create a package with the same contents as the one of loaded by MC.    and to have tags to only represent categories.
Now my time is short so I will    - probably not implement tags    - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange    code.    - check the MC dependency on method category conventions, because some logic is not defined in the right place     like overrides in the MC tools and not in the PackageInfo    - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to    associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames    and change the packages accordingly).    - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.
On Mar 19, 2011, at 8:39 PM, Igor Stasenko wrote:
I have no idea how Rpackage done internally but i think it should be orthogonal to MC.
a list of class and a list of methods smartly organized but no more.
You can implement import/export layers between MC and RPackage and make it follow any rules you want (current ones), but internal organization can be completely different.
Exact Now reproducing the matching of MC makes everything more complex.
On 19 March 2011 19:17, Guillermo Polito <guillermopolito@gmail.com> wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- Best regards, Igor Stasenko AKA sig.
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
Hi Stef, Thanks a lot for all this effort. I will reiterate again the original idea, which I still believe would work best. RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. Cheers, Doru On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com "When people care, great things can happen."
On Mar 19, 2011, at 10:55 PM, Tudor Girba wrote:
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes?
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
The problem is not publishing the problem is assigning classes to packages.
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
let us see imagine the following scenaro PI-Foo contains Foo Foo-Zork => We get RFoo and RFoo-Zork we can save and people can load now I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too in other system it will be in Foo ok we can load it Now if we should preserve the current loading semantics **package creation** when PI-Foo contains Foo Foo-Zork if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in. So we could always load and create a RPackage for each Category. This would be simpler.
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
yes
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
On 20 Mar 2011, at 09:18, Stéphane Ducasse wrote:
On Mar 19, 2011, at 10:55 PM, Tudor Girba wrote:
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes?
No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ...
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
The problem is not publishing the problem is assigning classes to packages.
I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below).
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
let us see imagine the following scenaro
PI-Foo contains Foo Foo-Zork
=> We get RFoo and RFoo-Zork
we can save and people can load now
I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too
in other system it will be in Foo ok we can load it
Now if we should preserve the current loading semantics **package creation**
when PI-Foo contains Foo Foo-Zork
if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in.
The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package. So, in your case, when you would open the NewMC, you would see in the list: Foo Foo-Zork Foo-Cat* The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently.
So we could always load and create a RPackage for each Category. This would be simpler.
In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories. Were my explanations clearer now? Cheers, Doru
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
yes
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
-- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."
Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage? Stef
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes?
No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ...
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
The problem is not publishing the problem is assigning classes to packages.
I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below).
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
let us see imagine the following scenaro
PI-Foo contains Foo Foo-Zork
=> We get RFoo and RFoo-Zork
we can save and people can load now
I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too
in other system it will be in Foo ok we can load it
Now if we should preserve the current loading semantics **package creation**
when PI-Foo contains Foo Foo-Zork
if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in.
The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package.
So, in your case, when you would open the NewMC, you would see in the list:
Foo Foo-Zork Foo-Cat*
The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently.
So we could always load and create a RPackage for each Category. This would be simpler.
In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories.
Were my explanations clearer now?
Cheers, Doru
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
yes
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
Hi Stef, I do not want to select the RPackage that maps to an MCPackage. This should be done transparently by the tool: 1 Category maps on 1 RPackage and this maps on a potential MCPackage. Let's take an example. You load the original MCPackage Foo: Foo Foo Foo-Bar We get 2 RPackages: Foo and Foo-Bar. We add a new RPackage Foo-Zoo. We open the NewMCInterface and we get three MCPackages: Foo Foo-Bar Foo-Zoo The Foo-Zoo MCPackage is offered without any explicit creation. Like this you take away the extra step and you control the mapping in the way you want. Cheers, Doru On 20 Mar 2011, at 10:04, Stéphane Ducasse wrote:
Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage?
Stef
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes?
No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ...
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
The problem is not publishing the problem is assigning classes to packages.
I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below).
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
let us see imagine the following scenaro
PI-Foo contains Foo Foo-Zork
=> We get RFoo and RFoo-Zork
we can save and people can load now
I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too
in other system it will be in Foo ok we can load it
Now if we should preserve the current loading semantics **package creation**
when PI-Foo contains Foo Foo-Zork
if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in.
The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package.
So, in your case, when you would open the NewMC, you would see in the list:
Foo Foo-Zork Foo-Cat*
The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently.
So we could always load and create a RPackage for each Category. This would be simpler.
In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories.
Were my explanations clearer now?
Cheers, Doru
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
yes
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com "Every successful trip needs a suitable vehicle."
Ok!!!! I love these examples. I thought that by mapping you meant mapping submatching categories
I do not want to select the RPackage that maps to an MCPackage. This should be done transparently by the tool: 1 Category maps on 1 RPackage and this maps on a potential MCPackage.
Let's take an example. You load the original MCPackage Foo:
Foo Foo Foo-Bar
We get 2 RPackages: Foo and Foo-Bar. We add a new RPackage Foo-Zoo. We open the NewMCInterface and we get three MCPackages: Foo Foo-Bar Foo-Zoo
The Foo-Zoo MCPackage is offered without any explicit creation. Like this you take away the extra step and you control the mapping in the way you want.
Cheers, Doru
On 20 Mar 2011, at 10:04, Stéphane Ducasse wrote:
Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage?
Stef
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes?
No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ...
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
The problem is not publishing the problem is assigning classes to packages.
I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below).
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
let us see imagine the following scenaro
PI-Foo contains Foo Foo-Zork
=> We get RFoo and RFoo-Zork
we can save and people can load now
I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too
in other system it will be in Foo ok we can load it
Now if we should preserve the current loading semantics **package creation**
when PI-Foo contains Foo Foo-Zork
if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in.
The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package.
So, in your case, when you would open the NewMC, you would see in the list:
Foo Foo-Zork Foo-Cat*
The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently.
So we could always load and create a RPackage for each Category. This would be simpler.
In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories.
Were my explanations clearer now?
Cheers, Doru
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
yes
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Makes sense to me ... Dale On Mar 19, 2011, at 2:55 PM, Tudor Girba wrote:
Hi Stef,
Thanks a lot for all this effort.
I will reiterate again the original idea, which I still believe would work best.
RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category.
The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages.
The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing.
In this way, we would be able to: - load existing MC without problems - publish new MCPackages that will be compatible with other dialects
Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too.
The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping.
Cheers, Doru
On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote:
On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote:
BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it.
In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes...
yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good.
But maybe it's easier (or nicer) to replace everything together... :P
Guille
On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich@vmware.com> wrote: Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
-- www.tudorgirba.com
"When people care, great things can happen."
On Mar 19, 2011, at 5:35 PM, Dale Henrichs wrote:
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
No this is not a problem, because we can save the package with the * notation and category even if we do not need that. What will happen is that pharo will only save package without subcategory matching (may be now resaving another the same package in another smalltalk may lead to a problem if the category are used as tags but not to have one to one correspondance). Let me explain: In Pharo I have Package Foo class InFoo has Category Foo (not needed in pharo but to help outside) class NotInFoo has Category Foo-Zork The class NotInFoo was edited with a simple class browser and the guy put a category Either the class NotInFoo is defined in Package Foo-Zork (and there is no problem when you load it elsewhere) Now if the class NotInFoo is defined in another package then when resaving in another system we may have a problem So this is why having a category to package mapping is safer. Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes. Tell me if this is making sense.
On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack....
Except that MC2 requires an implementation that is like RPackage not based on protocol matching because packages can contain the same methods.
Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ...
For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ...
One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2...
What I can tell you is that having fast static packages and cleaning MC name matching is good. Now I'm trying to find how we can map another semantics on top of RPackage to make the transition as smooth as possible and not only for pharo people. Stef
Dale
On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote:
Hi guys
we need to think about package:
right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement instead. RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence.
Now one of the problem I see is that we may not have a smooth transition because: - Rpackage does not rely on category tagging matching. - It is simpler to have a mapping from current categories to packages - Now it means that we could load a package in the system and it would be turned into several RPackages so this means that configuration would have to be adapted.
- marcus was suggesting me to create a package with the same contents as the one of loaded by MC. and to have tags to only represent categories.
Now my time is short so I will - probably not implement tags - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange code. - check the MC dependency on method category conventions, because some logic is not defined in the right place like overrides in the MC tools and not in the PackageInfo - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames and change the packages accordingly). - we should not rely on most-specific-category kind of pattern matching.
So if you have suggestion please talk now.
Stef
On Mar 19, 2011, at 2:18 PM, Stéphane Ducasse wrote:
On Mar 19, 2011, at 5:35 PM, Dale Henrichs wrote:
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
No this is not a problem, because we can save the package with the * notation and category even if we do not need that.
...........
Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes.
Stef, Over the long haul I would agree that migration to the newer model is a good idea and gemstone could install the code (when tool support becomes available in GemStone) and as long as there is a transition period where RPackage isn't _required_, then I think that things can work smoothly... Dale
Stef,
I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty.
No this is not a problem, because we can save the package with the * notation and category even if we do not need that.
...........
Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes.
Stef,
Over the long haul I would agree that migration to the newer model is a good idea and gemstone could install the code (when tool support becomes available in GemStone) and as long as there is a transition period where RPackage isn't _required_, then I think that things can work smoothly...
Yes I understand. Now we should be able to find a solution based on category (without subcat matching).
Dale
participants (6)
-
Alexandre Bergel -
Dale Henrichs -
Guillermo Polito -
Igor Stasenko -
Stéphane Ducasse -
Tudor Girba