Mathematica: Webel: ADT pseudo classes: POLICY: The ADT-Methods of an ADT-Class are created as TagSetDelayed UpValues using the 'signature' of the ADT-Class and its defining 'pattern' as 1st argument
Mathematica: Webel: ADT pseudo classes: CONVENTION: PROVISIONAL: The infix operator for calling ADT-Methods on ADT "objects" is the CircleDot (⊙ in Notebooks). ISSUE: \[CircleDot] is NOT GOOD FOR USE IN IDEs!
Mathematica: Webel: ADT pseudo classes: POLICY/DEFINITION: Every "hard coded" definer or defining client of a definer has a corresponding ADT ArchetypeClass. Example ("hard coded"): The definer 'my$def$MY$SmartList' has ArchetypeClass 'MY$SmartList'.
Mathematica: Webel: ADT pseudo classes: TIP: Prefer the Decorator Pattern over multiple inheritance of ADT-Method UpValues! (But not because "inheritance is evil", it isn't.)
Mathematica: Webel ADT pseudo classes: A tricky POLICY & CONVENTION: Client packages MUST access the special "wrapped" primary named ADT-parameter '$$' via $ContextAliases! The recommended alias is "A`" (which stands of course for ADT).
Mathematica: POLICY: Webel: ADT pseudo classes: Multiple inheritance is supported via ONE (only) ADT-Class and one or more ADT-MemberInterfaces (which have no ADT-Method UpValues)
Mathematica: Webel: ADT pseudo classes: POLICY: Definer functions MUST return the self-declared or injected 'pattern' that determines the unique "ADT-signature" of the defined ADT class.
Mathematica: POLICY: Webel: ADT pseudo classes that define membership of ADT-classes in a domain package have ADT-signature MemberInterface[$$:None] and MUST NOT populate ADT-method UpValues in their definers.
Mathematica: NAMING CONVENTION: Webel: ADT pseudo classes: An UpValue that can be invoked on an ADT accepting its unique 'signature' pattern as (at least) 1st argument is called an "ADT-method"'. They are NOT methods in the general object-oriented sense!
Mathematica: Webel: ADT pseudo classes: There is an 'ADT' universal base class that has no supers. It "blesses" every other sub-class ADT by populating it with some common ADT-method UpValues against its signature pattern via the 'adt$def$All[]' definer.
Mathematica: Webel: ADT pseudo classes: DEFINITION/CONVENTION: Functions that populate ADTs with reusable ADT-method UpValues are called 'definers' and include '$def' in the name after a Package scope indicator: Example: adt$def$ADT, my$def$MY$CleverList
Mathematica: Webel: ADT pseudo classes: POLICY: Every named concrete Abstract Data Type (ADT) class has a ONE unique "signature" (which is the pattern passed to the "definer" functions). To vary a signature, define another unique ADT class name.
Mathematica: Webel: ADT pseudo classes: POLICY: The Abstract Data Types (ADTs) are stateless functional (although inheritance and overrides are supported), with no caching by default (although there is nice optional caching using CreateUUID[] and Once[]).
Mathematica: Webel: ADT pseudo classes: The term 'Abstract Data Types (ADTs)' is used informally (the ADTs do not always adhere to strict mathematical definitions of ADTs). Just please think of it here as meaning a "strong type" for Mathematica.
Mathematica: Webel: You get compelling incremental value out of Mathematica even if you don't yet command all of the syntax and massive powers of the Wolfram Language!
Webel: SysML4Mathematica: Yes, SysML Activities and SysML Activity Diagrams CAN represent functional programming paradigms! You can type Parameters by encapsulations of functions and pass them to/from InputPins/OutputPins of Actions.
TIP: Mathematica: Use of For is often a hint that Map, Table, Scan, or something else more functional could be used. But don't stress over it!
"Everything now uses functional, nobody uses object-oriented anymore ... " WRONG: Grow up! Dr Darren (Webel IT)
Webel: Mathematica is functional programming on steroids (and has nearly everything else, except for decent in-built OO support, although you can make some progress with Abstract Data Types and even some inheritance).
Webel: Programmers who can count higher than one (1) know that you don't have to choose exclusively between object-orientation (and classes) and functional programming. You can have your cake and eat it. It's not XOR!