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

Mariano Martinez Peck marianopeck at gmail.com
Sun Aug 5 15:18:26 CEST 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120805/b37f4a50/attachment.html>


More information about the Pharo-project mailing list