[Glass] [GLASS] Compiling methods dinamically in

[Mariano Martinez Peck via Glass]

On Sun, Dec 7, 2014 at 2:21 PM, 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.
>

I don't have a GemStone handy right now, but maybe something like this
works:

'hello ^4' _compileInContext: nil symbolList: SymbolList new oldLitVars:
nil environmentId: 0

If you found nothing...then maybe another possibility is that you define a
strategy pattern and you do the compilation you know in Pharo and then in
GemStone you do what you find plus also deleting the method from the method
dictionary? (just thinking aloud a possible workaround).



>
> 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.
>
>
But the compilation code is just in one place, right? I would add a
strategy there so that you easily change the behavior from Pharo to
GemStone.


> 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?


No..that is not possible. I remember once we discussed that with Stef, Dale
and Martin...the idea was if GemStone could run Pharo kernel... but not,
it's not possible right now. Imagine all Pharo 3.0 core classes may not
work, several depend on primitives which may likely be different in GemStone
 etc..

I am curious about what is your meta-programming need, I mean...why you
need to generate compiled methods from strings. .Maybe if you describe that
a bit more it will help.




> 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
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141207/3df509bc/attachment.html>