Here are the goals I have for a dictionary class. A table is just a dictionary with (potentially multiple) key(s) and multiple values. A dictionary is a table with just one key and 1 value. Underlying storage should be at the most performant data type: If all keys or value (columns) are of the same/compatible types then they should be stored as such types. Only boxed if the "field" contains incompatible types. Object creation of the table/dictionary can impose type and shape restrictions. To accomplish the above, a list class that boxes items only when an item incompatible with the rest of the list is added is needed. Then columns just use that class interface to add/update values. The tradeoff is append/update checks/slowdowns in order to be able to obtain "clean" raw data/columns, but also avoid boxing if checks allow it. The checks may have less of a performance penalty than "upserting" (append/update) boxed structures. restricting types of table/dic at creation, further eliminates the checks, relying on errors when an incompatible type is added. An alternative simpler design is to have separate classes for dictionary/table maintained with boxed items, and one with raw items. Most applications do not require variable field types. Types and shape(with fill) restrictions can still be added at creation time in order to coerce values to that type. For boxed storage, items are boxed without checks. So both class types have better performance.
sugar functions for trimming variable shape columns (such as strings) make sense, and a default numeric list fill value of __ may be better than 0. _. is an option for fill value, but may harm performance more. __ or _. instead of 0 makes a floating point datatype storage though. Using a magic MAX/MIN_int would solve this, but create a bug in someone sometime's application that would be hard to track. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
