-
Notifications
You must be signed in to change notification settings - Fork 93
SegStringSymEntry to encapsulate Strings as single entity
This is one of the implementation approaches outlined in String pdarrays in Symbol Table Design Discussion Notes
- Single Symbol Table (keeps existing in place)
- Additional SymEntry called SegStringSymEntry which extends GenSymEntry
- SegStringSymEntry is a composite of the two SymEntry items which held the Strings components
offsets
andbytes
akasegments
andvalues
Since SymEntry is really a template for 4 different typed values of SymEntry we already have different types of SymEntries in the Symbol Table. Conceptually this adds to that design by including a fifth, albeit more complex, entry: SegStringSymEntry. It extends GenSymEntry
just like SymEntry does and includes a conversion utility for casting to its specific type.
There were a few common patterns that emerged during the implementation & design for this approach.
You can view SymEntry
as a general holder class of a typed array and domain. The common pattern for creating these are to allocate a domain/array combination, reserve an id/name in the SymTab
for use/interaction throughout the lifetime of the session, construct the Entry, insert it in the table, and return a message to the client containing its id and basic structure dimensions.
For the previous Strings approach we basically just doubled the above pattern for an offsets array and a separate bytes array (aka segments and values). A SegString
object was usually constructed as a temporary object comprised of these two SymEntry
's which contained various procedures for different types of operations.
This new implementation follows this pattern but encapsulates the two separate SymEntry
's into a single one so that only one item need be tracked in the SymTab
. Various factory methods have been added to aid the different construction patterns used throughout the server code. These factory methods generally funnel down to a single implementation which at the end of the day creates a SegStringSymEntry
, puts it in the SymTab
for tracking, and returns a SegString concrete object to be used by the rest of the server code. When a client wishes to interact with the object the server uses the appropriate factory method to retrieve the entry from the SymTab
by name/id and constructs a SegString object to perform the requested operation.
Most of the message passing between the client & server fall into the pattern of:
- Request an operation be performed on an object identified by an id/name (client -> server), return the result of that operation (client <- server)
- Create an object with values or using a procedure on the server to generate values, which returns the id/name of the object with basic meta-info.