Skip to content

SegStringSymEntry to encapsulate Strings as single entity

glitch edited this page May 27, 2021 · 6 revisions

This is one of the implementation approaches outlined in String pdarrays in Symbol Table Design Discussion Notes

Approach details

  • 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 and bytes aka segments and values

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.

Design details

There were a few common patterns that emerged during the implementation & design for this approach.

Construction & Access

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.

Message passing

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.