Client Smalltalk and GemStone Smalltalk

Previous chapter

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 similar to client Smalltalk in both organization and syntax. However, the range of classes and features available, and the class names and internal implementation of basic features like disk file access, varies considerably.

The GemStone class hierarchy is described in the GemStone Programming Guide.

SelectBlocks and other Indexing-related notation

Client Smalltalk implements similar ANSI protocol for block select and related operations, using square brackets.

SelectBlocks in GemStone Smalltalk were designed for use with the GemStone indexing framework, and are not present in client Smalltalk. SelectBlocks use curly braces and do not allow message sends other than specific comparison operators.

myEmployees select: {:ea | ea.age >= 18}

The use of dots for path notation, where each dot indicates that the following is the name of an instance variable on the former, is intended to support SelectBlocks in allowing access to instance variables in the absence of message sends. This has no counterparts in client Smalltalk.

Array Constructors

Array constructors do not exist in client Smalltalk (Both GemStone and client Smalltalk provide the ANSI standard Array literals, using the syntax #(literal literal)).

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. GbxTimeZone is set to the VisualWorks default TimeZone.

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:

For example:

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.

Previous chapter