[Pharo-project] About the migration from PackageInfo to RPackage

Stéphane Ducasse stephane.ducasse at inria.fr
Sun Aug 5 17:54:05 CEST 2012


Mariano 

I would suggest not to add the system Tanker but to develop it outside for now.
Else we will have to change it all the time.

Stef

On Aug 5, 2012, at 3:18 PM, Mariano Martinez Peck wrote:

> 
> 
> On Sun, Aug 5, 2012 at 2:33 PM, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> 
> On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote:
> 
> > What Mariano means is that you can have MCPackage(X) containing categories X-A, X-B, X-C.  When that package is loaded today, three RPackages are created: X-A, X-B, X-C.  So RPackages are more mapped from categories that from MCPackages.
> 
> we decided that it will be one package with classes having corresponding tags.
> But we should do it.
> Again nothing should be mapped from MCPackages (MCPackages should not be used it is an internal class of MC).
> 
> Ok, let me clarify something. First, let's decide where we discuss. Ok, here, not in the issue tracker. There you said: "You should not rely on MC layer for fuel.". First, it is not Fuel, it is Tanker. Second, the only think Tanker relies on is in a user-provided set of classes and extension methods. However, there is a separate package that helps using Tanker from RPackage or PackageInfo. Right now, if you have MCPackage X, and then categories X-A, X-B and X-C, then you have 3 RPackages. That's why I was talking about a "MCPackage mapping". If in the future, this is one RPackage then perfect. What I need to do is to have a RPackage for X where I ask classes and extension methods and it answers me also the included by its categories (X-A, X-B and X-C). To have that, is why I am using now #allDefinedClasses and #allDefinedExtensionMethods. 
> 
> 
>  
> 
> 
> 
> > > PackageInfo has a large APi that is often not used.
> > > So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a
> > > compatible interface.
> > > All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary
> > > backwards compat.
> > >
> > >
> > > I agree. But if you want to remove in the future PackageInfo, then RPackage HAS to provide a way to get the classes/extension methods of a MCPackage. That's why I need #allDefinedClasses and #allDefinedExtensionMethods
> >
> > Mariano if RPackage represents a MCPackage then RPackage offers all the correct queries to get the classes extended, method extensions and so
> > let me know if you do not see it because I payed extreme attention to that.
> >
> > RPackage>>defineMethodsForClass:
> >         definedSelectorForClass:
> >         extendedClassames
> >         extendedClasses
> >         extensionMethods
> >         extensionMethodsForClass:
> >         extensionSelectors
> >         extensionSelectorsForClass:
> >         methodsForClass:
> >         selectorsForClass:
> >
> > Let me repeat it. We do not need the compatibility layer.
> > Now it may be that (since rpackage was pushed fast in the image) that the importer from PackageInfo to Rpackage did not cover all the cases
> > but this is clearly another issue.
> >
> > Stef
> >
> > >
> > >
> > >
> > >
> > >
> > > What do you think?
> > >
> > > Stef
> > >
> > >
> > >
> > > --
> > > Mariano
> > > http://marianopeck.wordpress.com
> > >
> >
> >
> >
> 
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> 




More information about the Pharo-project mailing list