need your attention: Package
Locked
12
12
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 |
|
|
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 <[hidden email]> 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 |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
On 18 March 2011 21:56, Stéphane Ducasse <[hidden email]> 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. |
Re: need your attention: Package
|
|
In reply to this post by abergel
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 <[hidden email]> 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 > |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
On Mar 19, 2011, at 1:45 AM, Igor Stasenko wrote: >> > > 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. I would say that In the future, the idea is to not have categories at all. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: need your attention: Package
|
|
In reply to this post by Igor Stasenko
>
> 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. > |
Re: need your attention: Package
|
|
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. >> > > |
Re: need your attention: Package
|
|
In reply to this post by Igor Stasenko
On Mar 19, 2011, at 8:12 AM, Stéphane Ducasse 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. > Imagine we would at the same time abandon both PackageInfo *and* System Categories. Then you would just do: you have a MC package FOO it contains FOO-Cat1 --> One RPackage Foo you have a MC package FOO it contains FOO-Cat1 FOO-Dog2 --> One RPackage Foo. We loose the sub structure. For the sub-structure, the way categories are now used in PackageInfo packages is that they do not denote sub-packages, but just some convinient sorting without semantic (to the language) meaning, just as method categories. So the perfect thing would be to have some form of ordering inside of RPackage (e.g. tagging). The case "Now you create a new Category" would not exist, as there are no categories anymore. Categories should die. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
On Mar 18, 2011, at 9:56 PM, Stéphane Ducasse wrote: > > - 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 Even then, I would vote for mapping one PackageInfo --> one Rpackage. Categories are not packages, if we make every category a package we will end up in a big mess (as groups of these would have lots and lots of dependencies). Already the PackageInfo Packages for Network and Collection (the split into just the class categories - as- packages) was a mistake, purely driven by speed of MC. > - 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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: need your attention: Package
|
|
In reply to this post by Marcus Denker-4
Yes
I would love that. I'm concerned about the migration from current situation to the new ones. Stef On Mar 19, 2011, at 11:28 AM, Marcus Denker wrote: > > On Mar 19, 2011, at 8:12 AM, Stéphane Ducasse 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. >> > > > Imagine we would at the same time abandon both PackageInfo *and* System Categories. > > Then you would just do: > > > you have a MC package FOO > it contains FOO-Cat1 > > --> One RPackage Foo > > you have a MC package FOO > it contains FOO-Cat1 > FOO-Dog2 > > --> One RPackage Foo. We loose the sub structure. > > For the sub-structure, the way categories are now used in PackageInfo packages is > that they do not denote sub-packages, but just some convinient sorting without semantic > (to the language) meaning, just as method categories. > > So the perfect thing would be to have some form of ordering inside of RPackage (e.g. tagging). > > The case "Now you create a new Category" would not exist, as there are no categories anymore. > Categories should die. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > |
Re: need your attention: Package
|
|
In reply to this post by Marcus Denker-4
On Mar 19, 2011, at 11:31 AM, Marcus Denker wrote: > > On Mar 18, 2011, at 9:56 PM, Stéphane Ducasse wrote: >> >> - 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 > > Even then, I would vote for mapping one PackageInfo --> one Rpackage. But this is far from simple because you have then to deal with categories matching. I'm trying to see if I can do the following: At load time when I load Foo (ie the package Foo) I map Foo-zork and Foo-cat to Foo (if this is like that in the MC file) Now what is happening if the user create a new category Foo-tt Foo-tt will not be mapped to Foo. So what will happen? So I will try to understand how this is working right now and sync with cyrille. > Categories are not packages, if > we make every category a package we will end up in a big mess (as groups of these would have lots and lots > of dependencies). Already the PackageInfo Packages for Network and Collection (the split into just the class > categories - as- packages) was a mistake, purely driven by speed of MC. I do not think so. Collections should be repackaged. We should repackage the classes. > - 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 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > |
Re: need your attention: Package
|
|
In reply to this post by Marcus Denker-4
I have another problem is:
imagine we do not match category to package so this means that users will have to add explicitly their categories to the package So I load Foo I get the contents of Foo and Foo-B categories into RPackage Foo. I save Foo and it save the classes in Foo and Foo-B (categories are not considered just rpackage contents) Now I add a category Foo-C (because the browser let me do it) -> may be system should ask me: do you want to add to the Foo RPackage? -> may be I should do it explicitly Better is that we have a browser only showing RPackages Then what happen if I add a new class Zork in Foo-C The class category will be Foo-C and again does the system has to check in which package it should put the class? How do I map Zork class? -> explicitly? -> What happens if I do it via a browser only showing classes and categories? So the mapping Category to package is not that bad else we will have to check *****ALL***** the time if a class should be put in a package or not and compare category with package names. And we will have all the crap of matching with sub subc.... most specific categories.... So I would like to community to react to this mail because this is important and people will get frustrated after. I think that a one to one mapping to category is a good idea. + having a browser just showing packages would be good. Then we can after have a browser that show categories as tags and sort the classes accordingly. So people please thing a bit because I want to make progress and losing my time is boring. Stef |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
On 19 March 2011 08:11, Stéphane Ducasse <[hidden email]> 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. > 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. |
Re: need your attention: Package
|
|
On 19 March 2011 15:53, Igor Stasenko <[hidden email]> wrote:
> On 19 March 2011 08:11, Stéphane Ducasse <[hidden email]> 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. |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
On Sat, Mar 19, 2011 at 8:45 AM, Stéphane Ducasse <[hidden email]> wrote: I have another problem is: Yeap, I think that giving tool support is the key here. I don't like the implicit approach because it'll lead to miss-understandings and eventually RPackage can be used in several ways other than One-to-One with categories. So, something I'd like to ask, since I'm not entirely aware of the subject: Which are the concepts behind a Package and a Category? should they be the same or not? why? Guille
|
Re: need your attention: Package
|
|
In reply to this post by Igor Stasenko
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 <[hidden email]> wrote: >> On 19 March 2011 08:11, Stéphane Ducasse <[hidden email]> 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. > |
Re: need your attention: Package
|
|
In reply to this post by Guillermo Polito
On Mar 19, 2011, at 4:05 PM, Guillermo Polito wrote: > > > On Sat, Mar 19, 2011 at 8:45 AM, Stéphane Ducasse <[hidden email]> wrote: > I have another problem is: > imagine we do not match category to package so this means that users will have to add explicitly their categories > to the package > > So I load Foo > > I get the contents of > Foo and Foo-B categories into RPackage Foo. > > I save Foo and it save the classes in Foo and Foo-B (categories are not considered just rpackage contents) > > Now > I add a category Foo-C (because the browser let me do it) > -> may be system should ask me: do you want to add to the Foo RPackage? > -> may be I should do it explicitly > > Better is that we have a browser only showing RPackages > > Then what happen if I add a new class Zork in Foo-C > > The class category will be Foo-C and again does the system has to check in which package it should put the class? > How do I map Zork class? > -> explicitly? > -> What happens if I do it via a browser only showing classes and categories? > > > So the mapping Category to package is not that bad else we will have to check *****ALL***** the time > if a class should be put in a package or not and compare category with package names. > And we will have all the crap of matching with sub subc.... most specific categories.... > > So I would like to community to react to this mail because this is important and people will get frustrated after. > > I think that a one to one mapping to category is a good idea. > + having a browser just showing packages would be good. > > Yeap, I think that giving tool support is the key here. > I don't like the implicit approach because it'll lead to miss-understandings and eventually RPackage can be used in several ways other than One-to-One with categories. > > So, something I'd like to ask, since I'm not entirely aware of the subject: Which are the concepts behind a Package and a Category? should they be the same or not? why? RPackage does not rely on any conventions: everything is explicit: you add you methods/class to the package. Now my point is how to make the transition smooth. Stef |
Re: need your attention: Package
|
|
In reply to this post by Stéphane Ducasse
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 |
Re: need your attention: Package
|
|
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 <[hidden email]> wrote: Stef, |
Re: need your attention: Package
|
|
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 <[hidden email]> 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 <[hidden email]> 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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |