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