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

[James Foster via Glass]

Thanks for the comments and details about your project. While I assume that part of the assignment is to come up with a solution, I imagine that your professor is happy to have you come to the community for ideas. 

One idea would be to use blocks and then send #’valueWithArguments:’ to the block. There would be a bit of work parsing the method name and body, but you could add the method to a class, obtain the selector, and then parse the source to leave out the selector. You could then create a block and save it instead of your method. I think this code would be more portable.

Another approach would be to have a separate class for each object. At first it seems like a lot of overhead, but a class is just another object and your implementation provides for dictionaries holding methods—essentially a class!

> On Dec 7, 2014, at 9:31 PM, AleDanos via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> Wow, they weren't kidding when they said that GemStone has a very active and
> helpful community. In just 2 hours 3 people came offering help.
> 
> @James: Ok, thanks for the help. Your workaround does sound like a hassle
> (the one involving the "became:" message) and I don't think we have the
> knowledge necessary to apply it in time (we are familiar with the "became:"
> message but we have no practice using it and neither with the rest of that
> workaround) . It does sound really interesting though. Thanks.
> 
> And, yeah. It'd be great if someone went through the trouble of making
> GemStone and Pharo compatible but, as you've said, "I think this would be
> too much effort to make it worthwhile for any one project". I, for one,
> don't have the experience nor the time needed. Maybe in a few months.
> 
> @Mariano
> The "'hello ^4' _compileInContext: nil symbolList: SymbolList new
> oldLitVars: nil environmentId: 0" workaround raises an error when we try to
> run it in a Workspace ("Unexpected token" next to the word "hello" in the
> String) and when we try to debug it the debugger in turn raises another
> error (but the GemStone debugger never "worked" for us. It does show but for
> an error trying to show the debugger. Then we have to search for the method
> we are trying to debug in the Execution Stack of the Debugger).

The unexpected token is the ‘hello’ since this method is expecting something equivalent to the internals of a zero-argument block. 

> The "strategy pattern" workaround  to delete the method sound a little "too
> much" but also possible. We could use it as a last resort if nothing else
> works.
> 
> More info on the problem: we are students at Univerdad de Buenos Aires
> (UBA), Argentina and we are working on an assignment to implement Self
> functionality in Smalltalk. That is, to have objects that behave like in
> Self Programming Language (prototyping instead of classes, slots, parents,
> etc) [1].
> The assigment is divided in three stages:
> *Stage 1:* implement the aforementioned Self Objects in Smalltalk. Our
> approach was to have a "SelfObject" class that knows how to answer to the
> minimum amount of messages as possible. That way, when we send any message
> to an instance of said class we could intercept it with a DNU (does not
> understand) method. We had a "slots" dictionary as an instance variable as
> well as a "parents" dictionary as an instance variable. We also implemented
> Mirrors [2], a Method Lookup resembling the Self Method Lookup, etc.
> 
> *Stage 2:* After finishing Stage 1 we had to design a website using Seaside
> that provided the functionality of creating objects, accesing them, cloning
> them, etc; from a Web Browser (it was a little much harder than it sounds.
> Not from the Seaside part but from adapting what we did in Stage 1 and
> expanding it to provide what our Seaside website expected).
> 
> *Stage 3:* The final stage would be to add GemStone to the mix. That is,
> persist the website with GLASS (and some other minor things).
> 
> 
> @Richard Sargent
> It sounds like that would cut it (
> #compileMethod:dictionaries:category:intoMethodDict:intoCategories:). I'm
> out of time right now but i'll check it out tomorrow.

This is used to implement session methods (that aren’t persisted as part of the class). The problem for you is that the method will still apply to all instances of the class in that session.

> The problem with methods being automatically added is that then all of our
> Self Objects would know how to answer those messages. The idea was to
> compile a method and save it in the object's "slots" instance variable
> dictionary. Then, if someone sent the message "hello" to *that* SelfObject
> we would do the "method lookuping" and run the respective method for
> "hello". The set of methods implemented in the class should be kept to the
> minimum so all the instances can have different behaviour.
> 
> Thanks to all for your help.
> 
> [1] http://www.selflanguage.org/_static/published/self-power.pdf
> [2] http://bracha.org/mirrors.pdf
> 
> 
> 
> --
> View this message in context: http://forum.world.st/GLASS-Compiling-methods-dinamically-in-Gemstone-Importing-Pharo-3-0-classes-tp4794573p4794664.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