Porting GT code to GemStone

This page lists a few things to be aware of when writing code that is intended to be common between GT and GemStone, or when porting code to GemStone.

#new doesn't call #initialize

Two possible approaches:

Create custom instance creation methods that initialise the instance appropriately.

Override #new to do the initialisation:

Symbols are not callable

Symbols cannot be used to replace blocks as in Pharo. This means that this code

Should be rewritten as

Traits have to be inlined or rewritten

There is no trait support. As such they need to either be inlined—i.e. all methods and slots need to be transferred directly onto the traited class—or rewritten.

Class variables are saved to the DB

Class variable usage in GT tends to assume that the scope of the variable is the current user, but in GemStone it will be saved to the DB and used by all users, leading to potential unexpected behaviour.

GemStone provides the SessionTemps current dictionary, which can be used in a similar manner to Class variables.

Reflection is generally slow

Calls to #superclasses / #subclasses can be slow, e.g. a multi-terrabyte DB may take 1 second per call.

Either:

Rewrite the code to avoid reflection.

Store an initialised ClassOrganizer in SessionTemps.