We're working on support for OVER syntax (as part of SQL window functions) for a future release of IRIS. Feel free to reach out to me directly with more details on the specific requirements you have to see if they correspond to the feature set currently in the pipeline.

If you know which non-NoExtent (for lack of a YesExtent keyword :-) ) subclass of A you're targeting in B's subclass, you can override your property definition pointing to that subclass.

The Jupyter support is very exciting, adding a neat and highly appropriate mechanism for exposing IRIS-side concepts to a typical Python environment (Jupyter). This release is introducing a first taste of such an interaction, but we're very interested in learning from your experiences and ideas on making this even more effective at adding process control to your Python work. yes

Thanks for sharing Dave, great article!

As this is an area we'd like to develop further on the product end, we're very eager to hear customers' experiences and feedback on this.

Good question. Given our long history, we have a fair number of utility methods whose signatures grew organically and for which backwards compatibility goals have prevented us from doing significant cleanup. We're now in the process of reviewing the SQL utility methods and for the ones that really need as many parameters, are considering the use of an options string (aka compile flags), as is being used by some more modern infrastructure such as the work queue manager and/or just making separate specific methods rather than super-generic 10-argument ones. While we're at it, I'm eager to read suggestions or feedback on how others developing utility functions are dealing with this.

Depends a bit on what you want. If you want to use them in the WHERE clause, you can leave the "list of" structure as-is and use our %FOR SOME ELEMENT syntax. In your case, for retrieving them in the SELECT list, changing the projection or your data model is probably the pragmatic choice. Note that collections are a really powerful feature when working in the Object paradigm, but somewhat constrained by SQL standard operations when accessing through the relational paradigm.

Still not sure I'm entirely on the same page wrt the goal, but $translate is to replace individual characters with other individual characters (so 1 by 1). If you're looking for a proper function in ObjectScript, take a look at $zconvert(), which supports HTML and XML-escaping.