On Tue, Aug 11, 2009 at 6:28 AM, St�phane Ducasse <stephane.ducasse@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