Re: [Pharo-project] need your attention: Package
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.
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.
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
On Sat, Mar 19, 2011 at 8:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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? Guille
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
On Mar 19, 2011, at 4:05 PM, Guillermo Polito wrote:
On Sat, Mar 19, 2011 at 8:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
participants (3)
-
Guillermo Polito -
Marcus Denker -
Stéphane Ducasse