2009/8/10 Miguel Enrique Cob� Martinez <miguel.coba@gmail.com>
El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique Cob� Martinez
escribi�:
> 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.
>
> What are the pros/cons of this change?
>
> If feasible, will be marked as Milestone-1.0?

Ramiro Diaz Trepat and Mariano Mart�nez Peck commented on the magma
mailing list that they successfully loaded magma on a pharo image by
copying the extensions added by magma to BlockContext to the class
BlockClosure. It appear that the code worked ok. Maybe with this change
it wouldn't be necessary to modify magma (Chris Muller should speak
about this). That can be the case for a lot of packages and will ease
the integration and "certification" of several packages on pharo.

Miguel: Actually I was talking about Glorp, not Magma ;)

However, think I am not agree. In my case, Glorp has methods extensions (like *Glorp) in the BlockContext. But those methods were Glorp specific. So, the merge between BlockContext and BlockClosure has no sense.
If there are messages in BlockContext that you need to be in BlockClosure but are closure related, then perhaps we can put them, as there were already some (I remember for example, argumentCount).

This is a joke: Perhaps we can override the doesNotUndersand: in BlockClosure so that it delegates to BlockContext hahahahahah
�

See:

http://lists.squeakfoundation.org/pipermail/magma/2009-July/001321.html


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project