On Tue, Mar 23, 2010 at 6:21 PM, Stéphane Ducasse <[email protected] > wrote:
> > On Mar 23, 2010, at 4:38 PM, Mariano Martinez Peck wrote: > > > Ok. Done. In http://www.squeaksource.com/ObjectMetaTools > > > > you will find two packages: MethodWrappers and ObjectMetaTools > > > > ObjectMetaTools has ObjectTracer, ObjectViewer and ProtocolCatcher > (brought from Cuis) > > > > MethodWrappers has a first migration of the implementation of > MethodWrappers from here: > > > > http://www.squeaksource.com/ObjectsAsMethodsWrap > > > > It has some changes to the original implementation. > > > > - Instead of storing the old selector and the class in the wrapper, now > it is stored a MethodReference > > are you sure that this is better. > We should really clean methodReference because it holds information sich as > the version string that nobody understand the use > of it > no, I am not sure at all ;) ufffff you are completely right. It was "easier" to have a MethodReference but I didn't realize how many things were being kept there. I wouldn't remove MethodReference. I like the idea of having a lightweight proxy for CompiledMethod. Why you want to remove it ? can we make it better ? For example, now I can add class side methods to create instances but with only the things I need: the selector and the class. does it need a clean ? Thanks for looking at it :) > > > - Give another try to use directly methodDict at:put: to install and > uninstall wrapers, instead of addSelector: withMethod: > > - As an example, now there is an implementation of TestCoverage > > > > > > That's all for now. This is tested in 1.0 and 1.1 :) > > > > Cheers > > > > Mariano > > > > > > On Tue, Mar 23, 2010 at 4:03 PM, Stéphane Ducasse < > [email protected]> wrote: > > Why not? > > What would be good is to clean a bit the code of ObjectAsMethodWrapper > > May be having a better package name can help. > > > > Stef > > > > > > > > > Stef, I was thinking to put not only ProtocolCatcher but also all your > stuff from ObjectAsMethodWrapper in the same ObjectMetaTools. > > > > > > That way we have a repository with cool stuff > > > > > > what do you think ? > > > > > > cheers > > > > > > Mariano > > > > > > On Sat, Mar 20, 2010 at 5:12 PM, Mariano Martinez Peck < > [email protected]> wrote: > > > > > > > > > On Sat, Mar 20, 2010 at 4:44 PM, Stéphane Ducasse < > [email protected]> wrote: > > > Thanks I will do that! > > > can you open a ticket because the list is starting to get long of the > stuff to integrate after martin's changes. > > > > > > http://code.google.com/p/pharo/issues/detail?id=2180 > > > > > > BTW did you check if the other class besides ProtocolCatcher are > working? > > > > > > > > > No. No time yet. > > > > > > > > > Stef > > > > > > On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > > > > > This package should be removed from core but it should still be > loadable. Thus, when needed, they can be easily installed. On the other > hand, it could be in PharoDev image. > > > > > > > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have > any users in PharoCore > > > > > > > > To fix, evaluate: > > > > > > > > (MCPackage named: 'ObjectMetaTools') unload. > > > > > > > > I created and put such code in > http://www.squeaksource.com/ObjectMetaTools > > > > > > > > To load it again in a Pharo image: > > > > > > > > Gofer new > > > > squeaksource: 'ObjectMetaTools'; > > > > package: 'ObjectMetaTools'; > > > > load. > > > > > > > > During the week I will analyze the CUIS' ProtocolCatcher and see if > it make sense to put it there too. > > > > > > > > Cheers > > > > > > > > Mariano > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > [email protected] > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
