On Tue, Aug 11, 2009 at 6:28 AM, Stéphane Ducasse <stephane.duca...@inria.fr > wrote:
> OK so I did not get the ones that are missing for Glorp? > Sorry Stef I don't understood your question. Glorp uses some methods that wasn't in BlockCloure. At least, I remember one: argumentCount which was only a simple accesor. So, we put it in BlockClosure. Then, Glorp has extensions in BlockContext with category *Glorp that I had to copy them to BlockClosure, but those methods are Glorp specific and they are loaded only when you load the Glorp package. Best, Mariano > > Stef > > On Aug 11, 2009, at 9:18 AM, Adrian Lienhard wrote: > > > This was already discussed some time ago in the thread > > "BlockContextTest". Gabriel posted a list of methods and we discussed > > which ones should be copied to BlockClosure. > > > > Adrian > > > > On Aug 11, 2009, at 09:06 , Stéphane Ducasse wrote: > > > >> What would be nice is to get a list of the methods that are missing > >> in > >> BlockClosure. > >> After the changes will not be only needed for pharo but also for > >> Squeak since Squeak has blockclosure now > >> > >> Stef > >> > >>> > >>> http://code.google.com/p/pharo/issues/detail?id=1058 > >>>>> > >>>>> Can this two classes be merged (the share 80% or more than methods > >>>>> and > >>>>> several are identical, maybe were copied) and then (assuming that > >>>>> the > >>>>> BlockClosure will be the enduring): > >>>>> > >>>>> Smalltalk at: #BlockContext put: BlockClosure > >>>>> > >>>>> This way several packages that extend BlockContext will work in > >>>>> the > >>>>> new > >>>>> closure vm, for example Magma. > >>>>> > >>>> > >>>> I don't think this is a good idea. BlockClosures are *not* > >>>> contexts. > >>>> So methods > >>>> that are about the context part of BlockContext will fail. > >>>> > >>>> I think we should just keep BlockContext for backward-compatibility > >>>> in > >>>> 1.0. This > >>>> way, people can load code and than check if the methods needs to go > >>>> to > >>>> MethodContext > >>>> or BlockClosures. > >>>> > >>>> Marcus > >>>> > >>>> > >>> > >>> Ok, I assumed that like both classes share a lot of methods, they > >>> were > >>> mostly interchangeable. > >>> So by the responses, I think that this implies that changes will be > >>> neccesary to port packages that > >>> extend BlockContext to work in Pharo, while, at the same time, they > >>> must conserve the extensions to > >>> BlockContext. > >>> > >>> I imagine that given the closure integration in Squeak, this will > >>> force all the packages to use BlockClosure (or > >>> equivalent class) to update their packages. > >>> > >>> Miguel Cobá > >>> > >>>> > >>>> > >>>> -- > >>>> Marcus Denker - http://marcusdenker.de > >>>> PLEIAD Lab - Computer Science Department (DCC) - University of > >>>> Chile > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project@lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project@lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project@lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
