[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