Client Smalltalk and GemStone Smalltalk 
This appendix outlines the few general and syntactical differences between the VisualWorks and GemStone Smalltalk languages.
B.1 Language Differences
GemStone’s Smalltalk language is very similar to client Smalltalk in both its organization and its syntax. GemStone Smalltalk extends the Smalltalk language with classes and primitives to add multiuser features such as transaction support and persistence. The GemStone class hierarchy is extensible, and new classes can be added as required to model an application. The GemStone class hierarchy is described in the GemStone Programming Guide.
A quick look at the GemStone class hierarchy shows that it differs from the client Smalltalk class hierarchy in that classes for screen manipulation and the client Smalltalk programming environment don’t exist, and in that the GemStone Smalltalk hierarchy contains classes for transaction control, accounting, ownership, authorization, replication, user profiles, and indexing collections.
GemStone Smalltalk also introduces constraints and optimized selection blocks.
As a Smalltalk programmer, you will feel quite at home with GemStone Smalltalk, but you should take note of the differences outlined in this appendix.
Selection Blocks
Selection blocks in GemStone Smalltalk and the use of dots for path notation have no counterparts in client Smalltalk.
myEmployees select: {:i | i.is.permanent}
Array Constructors
Array constructors do not exist in client Smalltalk. In GemStone, array constructor syntax varies by server product and version. In GemStone/S 64 Bit version 3.0 and above, array constructors:
- use curly braces,
- use periods as separators,
- have no prefix, and
- can contain any valid GemStone Smalltalk expression as an element.
{'string one' . #symbolOne . $c . 4 . Object.new }
In 32-Bit GemStone/S and in GemStone/S 64 Bit version 2.x, array constructors:
- use square brackets,
- use commas as separators,
- are prefixed by #, and
- can contain any valid GemStone Smalltalk expression as an element.
#['string one', #symbolOne, $c, 4, Object new]
See the GemStone Programming Guide, Appendix A, for more details on Array constructors.
B.2 TimeZone handling
The GemStone server, as a multi-user system, may have a number of TimeZones installed, although only one is the current TimeZone for a particular session. The instances of TimeZone include the rules governing such things as the start and end of Daylight Savings Time. GemStone server TimeZones are created based on the Zoneinfo or Olson TimeZone repository.
DateTimes internally store the time in UTC (GMT), but display themselves based on the local current TimeZone. DateTimes do reference an instance of TimeZone, but most server operations use the gem’s current TimeZone.
When server DateTimes are replicated to client TimeStamps, the GbxTimeZone is used to determine the TimeStamp’s correct current local time. How the GbsTimeZone is set depends on the version of VisualWorks.
In VisualWorks version 7.7 and above, which implements a similar TimeZone scheme as GemStone, the GbxTimeZone is set to the VisualWorks default TimeZone.
In VisualWorks versions prior to 7.7, the gem’s current TimeZone instance is replicated to the VisualWorks client for the GbxTimeZone.
If the desired TimeZone is not the VisualWorks default, or if the GBS application changes the gem's current TimeZone after a session has logged in, GBS cannot detect this. In this case, the client application needs to send the new message
GbsSession >> setClientTimeZoneFromServer
to re-replicate a copy of the timezone.
To explicitly set a specific time zone for the client, you can create the desired TimeZone on the server, and replicate it to the client, using the method
GbsSession >> clientTimeZone:
myGbsSession clientTimeZone:
(mySession evaluate: 'TimeZone
fromGemPath:''/foo/bar/America/New_York''').
This would be the case if the gem and client are in different time zones, and you want the timezone to be same between the gem and client (in VisualWorks version 7.7 and later).