Dr Darren of Webel IT Australia makes the case for better object-orientation for Mathematica using pseudo class ADTs without losing the super-functional power of the Wolfram Language

As one of the biggest fans of graphical Systems Modeling Language v1 (SysML^®) for Model-Based Systems Engineering you are likely to ever meet, and given that I am working on integrating Mathematica with SysMLv1 and SysMLv2, I have specific needs. SysML is primarily object-oriented; SysMLv1 uses Blocks, which are UML Classes "on steroids" adapted for use beyond software engineering. SysMLv2 has PartDef and Part instead, which have more flexibility than SysMLv1 Blocks, but are still primarily object-oriented (and not just in the software coding sense).

But even without using Mathematica for my SysML work, there is a need for at least the fine-grained organisational and role-distilling power that Classes offer. I've been using Mathematica for very complex projects (such as modelling air conditioning systems), with SysML modelling in parallel as I go, and it's simply super having that SysML support. For example, I use SysML Activity Diagrams to model and refactor a lot of my Wolfram Language code.

Until recently, I had been using with true gratitude the user-contributed MTools, which, although a valiant effort, does not meet all my needs, including this major issue:

My recent exploration of implementations of what I describe as "pseudo class" ADTs, and my successful implementation of a form of inheritance for them, has convinced me that (greatly adapted) stateless Abstract Data Types (ADTs) are the way to go for my purposes for many of my Mathematica projects in future.

I've introduced some very clear new terminology for the Webel ADT recipe, that is explained in this new trail section, in the many linked POLICY note pages:

Before listing some advantages of the Webel ADT approach, please let me make this very clear. ADTs in Mathematica are not to be directly related to the concept of classes you may know from most OO languages! They use expressions, they attach to the "super functional" capabilities of Wolfram Language and Wolfram Language Patterns, and they go far beyond anything that generics (Java) or usual OO templates (such as C++) might offer. They can be generated easily, on-the-fly, and can address many of the issues the best known Design Patterns of OO might otherwise address in a dedicated OO language.

Please note carefully also:

I have decided in part to adopt this approach so that my ADT implementation offers an alternative to MTools, and forces me to think in a more "Mathematica functional" way.

The topic of visibility (package, private, protected, public etc.) is currently completely out-of-scope.

Some good things about the Webel ADTs so far

• Super suitability to modelling in SysML! Each ADT-Class maps to a SysMLv1 Block, the ADT-Method UpValues to Operations, the top-level (non ADT) supporting functions map to SysML Activities, and I have a complete set of new SysML Stereotypes with keywords and icons for every concept in the Webel ADT recipe.
• Thanks to some naming conventions and some context management tricks, a very concise coding recipe, easily accessed also from client packages of the main ADT` package.
• Far better organisational power than just using Paclets and single .m or .wlPackage files. It enables to establish roles, identify responsibilities, and code cleaner.
• Being able to use ADT pseudo class "strong types" in argument patterns for functions is way, way easier for me than just using regular patterns. Don't leave home without it. And no, you won't lose the power of Wolfram Language Patterns, I'll show you exactly how as we go.
• The Webel ADT coding pattern works well (but not perfectly), in the simply super duper wonderful Wolfram Language Plugin for IntelliJ IDEA, my new great source of joy (and it makes my coding hands happier too). It can't catch the (contrived) Webel ADT inheritance hierarchies, but it's otherwise pretty good, and the IDEA has some cool filtering features, such as sorting by UpValues etc. Refactoring Wolfram Language "variable" names? No issue!
• I have some terrific new quick help utilities and development utilities that work not just with the ADTs, but with any expression, such as nice UpValues (including ADT-Method) searching, extraction ADT-Methods signatures, and more. Makes Notebooks even more fun.
• Reuse through inheritance (but by choice, multiple inheritance is restricted to only being allowed in combination with Webel ADT-MemberInterfaces, explained in the main tutorial section, and modelled in SysMLv1 using InterfaceBlocks).
• Use of "passive" ADT-MemberInterfaces (no ADT-Method UpValues) to define membership of ADT-Classes within a role or domain, and if needed at a finer grained level than a Package file. See XL:XL in the image above.
• Graphs of inheritance hierachies! OpenerView trees of hierarchies! Navigate generated content with clear OO-like structure and "class meaningful" views in interactive Manipulate GUIs.

And all while having my OO cake as I eat my Wolfram functional too. To learn more, start this technical slide trail section: