[Pharo-project] About the migration from PackageInfo to RPackage
Hi guys 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. What do you think? Stef
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Hi guys
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
What do you think?
Stef
-- Mariano http://marianopeck.wordpress.com
On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi guys
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
Unless we attack MCPackage at the same time
What do you think?
Stef
-- Mariano http://marianopeck.wordpress.com
On Sun, Aug 5, 2012 at 1:48 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:
On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi guys
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
Unless we attack MCPackage at the same time
And do what? you said in the issue tracker: "I believe that for tanker you should specify the exact package names..." Well, of course, I can do it myself (in my own code) but if every person that needs to map MCPackages to RPackage does it in their own.... I don't care if you provide #allDefinedClasses and #allDefinedExtensionMethods. What I think is a must if you want to remove PackageInfo is to provide a map between MCPackage and RPackage. I other words, say I have the MCPackage 'Fuel', how do I get the list of classes and extension methods?
What do you think?
Stef
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
I do not get why do you use MCPackage There is ring for that and MCPackage one day will disappear. MCPAckage is just an internal abstraction of Monticello to represent a bunch a classes. You confused me. Fuel should be concerned about RPackage not MCPackage. MC should deal and build its MCPackage based on RPackage (now it is using PackageInfo) Fuel should not be based on Monticello abstractions. Stef
And do what? you said in the issue tracker: "I believe that for tanker you should specify the exact package names..."
Well, of course, I can do it myself (in my own code) but if every person that needs to map MCPackages to RPackage does it in their own....
I don't care if you provide #allDefinedClasses and #allDefinedExtensionMethods. What I think is a must if you want to remove PackageInfo is to provide a map between MCPackage and RPackage. I other words, say I have the MCPackage 'Fuel', how do I get the list of classes and extension methods?
What do you think?
Stef
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi guys
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
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. On Sun, Aug 5, 2012 at 2:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Hi guys
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
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).
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
AFAIK, we decided (because that was the best migration path possible), when you have packages X, X-A, X-B, X-C, just to keep package "X", then add class tags (A, B, C) to corresponding classes. Of course that also means that we need to update tools (nautilus) to show that tags, but thats no so difficult. Esteban On Aug 5, 2012, at 2:33 PM, Stéphane Ducasse <stephane.ducasse@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).
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
Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ? Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ? I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ? At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0). Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : dimanche 5 août 2012 14:44 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage AFAIK, we decided (because that was the best migration path possible), when you have packages X, X-A, X-B, X-C, just to keep package "X", then add class tags (A, B, C) to corresponding classes. Of course that also means that we need to update tools (nautilus) to show that tags, but thats no so difficult. Esteban On Aug 5, 2012, at 2:33 PM, Stéphane Ducasse <stephane.ducasse@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).
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
On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote:
Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ?
Which package classes? because MC use a pattern matching based on category names and explicitly MCworking copy So if you declare an MC package we name X and X-A indeed you are in trouble. The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories.
Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ?
I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ?
yes
At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0).
Thierry ________________________________________
Well, what happened is that I renamed a package in Nautilus (from X-B to X-C, knowing there was already a X-A). It moved things from X-B to X-C, and created X as well. Now I erase X working copy on a regular basis (it's the Alt package you get when you load Alt-Browser), noticing today thanks to the discussion that RPackage was keeping a copy of Alt as well, so I unregistered it today. I hope I finally got rid of it ! Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : dimanche 5 août 2012 17:47 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote:
Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ?
Which package classes? because MC use a pattern matching based on category names and explicitly MCworking copy So if you declare an MC package we name X and X-A indeed you are in trouble. The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories.
Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ?
I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ?
yes
At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0).
Thierry ________________________________________
Nautilus displays too many packages :) We will have to fix that but ben is basically waiting for me to move on RPackage but I'm burnt on it. Stef On Aug 5, 2012, at 5:59 PM, GOUBIER Thierry wrote:
Well, what happened is that I renamed a package in Nautilus (from X-B to X-C, knowing there was already a X-A). It moved things from X-B to X-C, and created X as well.
Now I erase X working copy on a regular basis (it's the Alt package you get when you load Alt-Browser), noticing today thanks to the discussion that RPackage was keeping a copy of Alt as well, so I unregistered it today. I hope I finally got rid of it !
Thierry
________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : dimanche 5 août 2012 17:47 à : Pharo-project@lists.gforge.inria.fr Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage
On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote:
Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ?
Which package classes? because MC use a pattern matching based on category names and explicitly MCworking copy
So if you declare an MC package we name X and X-A indeed you are in trouble. The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories.
Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ?
I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ?
yes
At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0).
Thierry ________________________________________
On Sun, Aug 5, 2012 at 2:33 PM, Stéphane Ducasse <stephane.ducasse@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
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@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.
Mariano before RPackage fully works we cannot promise anything. So I suggest to test tanker only on package without X-A patterns then in addition making progress on that front: - helping for package-info tag import - do not use MCPackage - do not use the compatibility layer of RPackage Sorry but this is the only answer I have right now. First fixing the systemAnnouncer to fully work then slowly checking packageInfo api then cleaning PackageOrganizer then rethinking the import of RPackage and map fucking categories to tags). then ... Stef
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@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
Hi Stef, what would be the suggested API then ? And in announcements, would that change the returned type of some events (MCWorkingCopyCreated / MCWorkingCopyDeleted) ? For Alt-Browser to navigate through the packages, I use MCWorkingCopy and PackageInfo. Is this the way it should be done ? Should I use RPackage instead ? Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : dimanche 5 août 2012 13:28 à : Pharo-project@lists.gforge.inria.fr Development Objet : [Pharo-project] About the migration from PackageInfo to RPackage Hi guys 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. What do you think? Stef
Hi Stef,
what would be the suggested API then ?
All RPackage methods without the compatibility layer.
And in announcements, would that change the returned type of some events (MCWorkingCopyCreated / MCWorkingCopyDeleted) ?
For Alt-Browser to navigate through the packages, I use MCWorkingCopy and PackageInfo. Is this the way it should be done ? Should I use RPackage instead ?
yes. We will remove PackageInfo. The first step will be to keep inside PackageInfo only the methods used. Then make sure that we can have the same behavior with RPackage. MCWorkingCopy is just the repository for MC world.
Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : dimanche 5 août 2012 13:28 à : Pharo-project@lists.gforge.inria.fr Development Objet : [Pharo-project] About the migration from PackageInfo to RPackage
Hi guys
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.
What do you think?
Stef
participants (5)
-
Esteban Lorenzano -
GOUBIER Thierry -
Guillermo Polito -
Mariano Martinez Peck -
Stéphane Ducasse