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

[AleDanos via Glass]

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

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.