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

[Richard Sargent via Glass]

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

As James has mentioned, creating classes on the fly is probably your best
bet for making Smalltalk emulate Self. Copy the method and category
dictionaries from the prototype to the new class, compile the methods
specific to the new class, and away you go.

This has the best chance for success, as it is viable in both Pharo and
GemStone and it plays to Smalltalk's model.

As a general guideline, you want Smalltalk applications to play within the
Smalltalk design. The further from this you go, the more work you have to do
and the less your chances of success. As long as you can play within the
model, you should be able to do so "easily". :-)



> 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-tp4794573p4794670.html
Sent from the GLASS mailing list archive at Nabble.com.