Mathematica: Webel ADT pseudo classes: ADTs 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.

Webel IT Australia promotes the amazing Mathematica tool and the powerful Wolfram Language and offers professional Mathematica services for computational computing and data analysis. Our Mathematica tips, issue tracking, and wishlist is offered here most constructively to help improve the tool and language and support the Mathematica user community.
DISCLAIMER: Wolfram Research does not officially endorse analysis by Webel IT Australia.
Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
POLICY
Policy level
STRICT
Keywords
Click on the image to view it full size
Such ADTs are called ADT MemberInterfaces in the Webel recipe. They may participate in multiple inheritance ONLY because they DO NOT define (generate) any ADT-method UpValues. For an example visit:
Mathematica: Webel ADT pseudo classes: A tricky POLICY & CONVENTION: Client packages MUST access the special "wrapped" primary '$$' via $ContextAliases! The recommended alias is "A`" (which stands of course for ADT).
IMPORTANT: Webel: The definer of an ADT MemberInterface is NEVER called by a client sub-class definer if that client sub-class is involved in multiple inheritance via another ADT-Class (that generates ADT-Method UpValues)!

It may be called by a client sub-class definer that only wishes to inherit the functionality of the universal base ADT whilst "inheriting" an otherwise passive membership role, and otherwise defines all of its own ADT-method UpValues.

Note that an ADT-Class participating in multiple inheritance will get those base ADT ADT-method UpValues (against its own injected signature) through the one (1) allowed concrete ADT it extends.

You could if you really wish include ADT-method UpValues in an ADT MemberInterface if you really enjoy really, really hard to trace bugs. A better and more enjoyable approach (even if it is sometimes a bit tedious) is:

Mathematica: Webel ADT pseudo classes: TIP: Prefer the Decorator Pattern over multiple inheritance of ADT-Method UpValues! (But not because "inheritance is evil" per se, it isn't.) The base ADT libraries make heavy (and very useful) use in inheritance.
Relates to
Mathematica: POLICY NOTES for the Webel Abstract Data Type (ADT) pseudo classes with inheritance for the Wolfram Language
Creating new ADTs that extend other classes using a definer function (and adt$addSuper)
Related notes
[CONVENTION, NAMING]{STRICT} Mathematica: Webel ADT pseudo classes: NAMING CONVENTION: 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!
[CONVENTION, POLICY]{STRICT} Mathematica: Webel ADT pseudo classes: POLICY: Every named concrete Abstract Data Type (ADT) has a ONE unique "signature" (which is the pattern passed to the "definer" functions). To vary a signature, define another unique ADT name.
[CONVENTION, POLICY]{STRICT} 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[]).
[POLICY]{STRICT} Mathematica: Webel ADT pseudo classes: POLICY: The expression '$$' is reserved as the primary named parameter for the defining pattern of all ADT classes that extend the universal base 'ADT' class.
[POLICY]{STRICT} Mathematica: Webel ADT pseudo classes: There is an 'ADT' universal base that has no supers. It "blesses" every other sub-class ADT by populating it with some common ADT-Method UpValues against a signature pattern via the 'adt$def$All[]' definer function.
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)