[Glass] [GLASS] Compiling methods dinamically in
AleDanos via Glass
glass at lists.gemtalksystems.com
Sun Dec 7 09:21:41 PST 2014
Hi, we're having some problems importing our *Pharo 3.0* code into GemStone.
More specifically, meta-programing code.
In Pharo 3.0, given a class you can ask for its compiler and compile methods
for it easily. These methods can then be run dynamically for a recipient
object and the arguments the method requires.
In GemStone, we couldn't find this functionality of just asking a class for
its compiler. Instead we found out that there's a message #compile found in
the class methods for class Behaviour. We tried this message out and it
compiles code (strings) but it automatically assigns the resulting method to
the method dictionary of the class of the recipient object of the message.
C compile: 'hello', String cr, '^4'
... running that collaboration would add a new method for message #hello in
class C with the corresponding code. Instances of C now can answer to the
On the other hand, in Pharo 3.0
code := 'hello', String cr, '^4'.
aCompiler :=C compiler
failBlock: [ ^nil ].
aCompiledMethod := aCompiler translate generateWithSource.
...aCompiledMethod would be a compiled method "cooked" for instances of
class C but it wouldn't be added to the method dictioary of Class C:
instances of Class C don't know how to answer the message #hello. So, if we
wanted to send the message "hello" to an instance X of class C then we would
run that method with X as the recipient object and no arguments:
aCompiledMethod valueWithReceiver: X arguments: #()
¿Is there a way to do something of the sort in GemStone? That is, compile
methods dynamically without them auto-adding-themselves on the methods of a
Class. In other words, to have standalone methods.
Everything we did on Pharo 3.0 is coupled to the way we compile methods. We
would like it if we could import our code into GemStone without having to
The best solution would be to be able to move *all of the pre-existant*
classes that we are using in Pharo 3.0 to GemStone. That way, our developing
enviroment (Pharo 3.0) would be independent of our persisting environment
(GemStone). ¿Is there a way to do it? More generally, ¿Is there a way to
move all of *Pharo 3.0* to GemStone? I'm aware that Pharo has classes that
wouldn't make any sense in GemStone, like the ones responsible for the GUI,
but that shouldn't be a problem. They wouldn't make sense but they wouldn't
View this message in context: http://forum.world.st/GLASS-Compiling-methods-dinamically-in-tp4794573.html
Sent from the GLASS mailing list archive at Nabble.com.
More information about the Glass