Skip to content

String pdarrays in Symbol Table Design Discussion Notes

glitch edited this page May 11, 2021 · 1 revision

Stemming from Issue#786 we want to investigate various designs to store complex objects in the Server-side symbol table. This is in contrast to the current implementation where complex objects are a composite of semi-loosely coupled pdarrays stored on the server but managed and coupled on the client.

We plan to use the Strings class on the Python client-side as a proof-of-concept to migrate to the server side as a complex object.

Goal:

To store complex objects in the MultiTypeSymbolTable.SymTab

Plan:

Start with client-side Strings class which is a composite of two pdarrays; one containing the bytes and the other containing the offsets to the beginning of each string. On the server side this is a SegmentedArray.SegString which contains handles to the two SymEntry objects. We'd like to encapsulate this completely in its own class and store it in the SymTab as its own entry.

Broad Implementation Approaches:

  • Separate SymTab (i.e. ComplexObjSymTab) which contains Complex Object (one or more pdarrays, multi-dimensional arrays, etc.) This has an advantage of cleanly separating the newer functionality from the current SymTab. We could try to slowly migrate object types to this table over time, but it would require a bit of duplication of code and added complexity to route requests to the proper table.
  • Increase sub-classes of GenSymEntry / SymEntry and continue to operate in current SymTab. Here we could update GenSymEntry to act as an interface and try to spec out additional methods to support a broader class of types. If we can operate throughout the code cleanly with GenSymEntry then the concrete implementations can do the heavy lifting. i.e. We could make a SegStringEntry:GenSymEntry which would be a container/holder for a SegString object which held the two pdarray objects directly. In this approach we could try and keep the current SymEntry intact and fill in newer methods with UnsupportedOperationException type errors (which shouldn't really hurt anything since nothing would be calling them).