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.
> 
> 


Reply via email to