[Glass] [GLASS] Compiling methods dinamically in Gemstone / Importing Pharo 3.0 classes

Richard Sargent via Glass glass at lists.gemtalksystems.com
Sun Dec 7 11:48:54 PST 2014

AleDanos wrote
> 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.
> Examples:
> In Gemstone, 
>     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 message #hello
> On the other hand, in Pharo 3.0
>     code := 'hello', String cr, '^4'.
>     aCompiler :=C compiler 
> 		source: code;
> 		requestor: nil;
> 		category: '';
> 		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 rewrite everything.
> The best solution would be to be able to move the base 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 hurt
> either.
> Thanks.

The Behavior method
#compileMethod:dictionaries:category:intoMethodDict:intoCategories: might
work for you. In this method, you provide the method and category
dictionaries into which the method is inserted.

You should also look into session methods.

Ultimately, we can best recommend a GemStone solutino once we understand
your use case. What problem is your Pharo solution addressing? Why don't you
want your methods in the class?

View this message in context: http://forum.world.st/GLASS-Compiling-methods-dinamically-in-Gemstone-Importing-Pharo-3-0-classes-tp4794573p4794603.html
Sent from the GLASS mailing list archive at Nabble.com.

More information about the Glass mailing list