Wrappers: an example of complex objects

In our discussion on 4/1, we talked at a high level about the need to support complex objects in the server (Chapel), so that we can migrate existing client-side objects to the server, for better performance and a slimmer client. Wrapper objects provide a good illustration of why this is important. There are two examples of wrapper objects already in the Arkouda client: ak.Datetime and ak.Timedelta. These classes are wrappers around int64 pdarray objects that do two main things:

1. Display values to the user as dates/times
2. Implement the semantics of datetime operators

I have prototypes of other wrappers for bit vectors and IP addresses that are very similar. These client-side objects do an ok job with operators and methods, but it gets tough when you use them with module-level functions. For example, calling ak.concatenate([a, b]), where a and b are ak.Datetime objects returns an int64 pdarray. Why? Because the server-side Chapel code does not know what a Datetime is, and so it thinks the client is just asking it to concatenate two int64 arrays into another int64 array. Thus, the user or the client must re-convert the result to ak.Datetime, which is ugly and error-prone. Having the server understand and return Datetime as a native type would solve this problem.

In one sense, these wrapper objects are simple, because they only have one constituent array (unlike Strings, DataFrame, GroupBy, etc.). However, in another sense they are complex, because they need to support operators, which might be a headache the way the code is currently written.

Two questions for the group:

1. Would it make sense to implement these wrapper objects in Chapel before or after things like Strings and GroupBy?
2. How would you handle operators on these objects?