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.