Symbolic references
Symbolic references allow object spaces to implement primitive naming services. You can export objects in a local space using a symbolic name and then reference the object remotely using just the object name and the space containing the object. With symbolic references, the identity of an indicated object is not known until the reference is resolved by the space holding the object. As a result, two consecutive messages sent to the same remote reference may actually go to two different objects, if the name/object binding was changed between the messages.
Thus, the expression:
(#ObjectName sstIn: aSpace) yourself == (#ObjectName sstIn: aSpace) yourself
may answer false because the remote references created by sstIn: are symbolic and do not preserve identity. That is, the object registered under the key #ObjectName in aSpace could change between sends of yourself, resulting in different objects being returned. (In some systems, the yourself message is never sent. This example assumes yourself is always sent.)
Globals within an image can be addressed using code like--
(#Compiler sstGlobalIn: aSpace)
This code returns a remote reference to the Compiler (Smalltalk at: #Compiler) in aSpace. Also, global remote references are symbolic and do not preserve identity. Further, the reference building constructs such as sstGlobalIn: and sstIn: do not cause remote messages to be sent. It is only when these references are message receivers do remote messages get sent.
Symbolic global references are available when using native SST messaging only. Global references of this kind present a security risk as clients are able to find and manipulate objects in your server. You can disable the ability to resolve global references and disallow incoming global references by setting the allowGlobalReferences option in the space configuration you are using to false.
The ping-pong examples contain both types of reference. When references are exported from object spaces, it means that they become accessible to other machines. The ping-pong objects returned from createPingAndPong are implicitly exported as transient references in all the by-reference hierarchy examples but are explicitly exported as symbolic references in the by-value example.
Last modified date: 01/29/2015