[Glass] [GLASS] Compiling methods dinamically in
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Mon Dec 8 10:12:28 PST 2014
Well, this is about as close as I think you can come in GemStone:
| methodDict meth instance |
methodDict := GsMethodDictionary new.
meth := Array
_primitiveCompileMethod: 'hello ^''hello'''
symbolList: System myUserProfile symbolList
category: #'xxyzzy'
oldLitVars: nil
intoMethodDict: methodDict
intoCategories: GsMethodDictionary new
intoPragmas: nil
environmentId: 0.
meth _executeInContext: Array new
With #_primitiveCompileMethod... you can compile a method in the context
of a Behavior and avoid having the method installed in the method
dictionary by supplying a substitute GsMethodDictionary (methodDict). Then
you can execute one of the methods using #_executeInContext: where you pass
in the instance against which you want the method run ...
Note that #_executeInContext: does not take any arguments, so if you need
to pass in arguments things get a bit more complicated and depending upon
your use case might not quite work the way you want ...
On Sun, Dec 7, 2014 at 9:21 AM, AleDanos via Glass <
glass at lists.gemtalksystems.com> 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 *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
> hurt either.
>
> Thanks.
>
>
>
> --
> 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.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141208/fecca51d/attachment.html>
More information about the Glass
mailing list