On 18 March 2011 21:56, Stéphane Ducasse <[email protected]> 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.
