Mynx Method Obviates All for One, but One for All or Something Like That...

Method obviation allows a software developer to simplify the class functionality, to remove obsolete or deprecated methods in a sub-class.

Mynx Method Obviation

Mynx has a feature to obviate, or remove from the class interface/protocol methods from a super-class (if you do not want to create a method in the class, then do not or make it private...) to simplify the sub-class interface/protocol.

Method obviation is of one of two forms:

1. All - obviate all methods by the method name.


2. One - obviate one method by the method name and parameter list.

There are semantic rules for method obviation listed in the Mynx Programming Language Manual (MPLM), but one specific rule impacts the implementation and design of the compiler.

Mynx Obviate Semantic Rules

The specific semantic rule that impacts the compiler is that Mynx method obviates must be mutually exclusive to avoid obviation ambiguity--a method cannot be obviated specifically for one kind of method, and then all the methods of the same name obviated. For example, consider the Mynx class:

class badObviate as someSuperClass is

     //obviate specific method
     method noDuh(Int) as void;
 
     //obviate all methods
     method doNop as all void;   

     //obviate all but conflicts with specific
     method noDuh as all void;  

end class;

Why the concern about overlapping method obviates? The ambiguity is not that the specific method is obviated, or all of them -- but what specifically? All or one, one or all? (To paraphrase from the Three Musketeers...)

Compiler Internals for Method Obviates

Internally, the compiler is constructed to use a map data structure (called an OrderedMap--a hand crafted class for efficiency and efficacy in the compiler design) to associate the specific signature of an obviate method with the sentence that declares the method obviate. The Mynx class obviates return a specific key as a String for the method obviate.

Two maps are used, one for the obviate of all methods (the key the method identifier as a string), and one for the obviate of one method (the key the method identifier and parameter list of specific types as a string).

Both maps ensure another semantic constraint--uniqueness. No method obviate can be repeated or re-declared, just like any other declaration must be unique in context of unit or method.

The snafu is in the mutual exclusiveness constraint; originally I had intended to check the obviate mutual exclusiveness on the fly, as obviates are inserted into each map. However, in contemplating the use cases of possible Mynx classes, using two separate maps has the problem that later on a method for all method obviation might conflict with a method inserted earlier for one method obviation--remember the key is the method name and parameter signature, not just the method name.

Implementing Method Obviate Semantics

One approach is to use a short method name map that shadows the obviate map for one method. After a obviate declaration for all is checked against duplicates in its own map, it is then checked against the shadow map. Of course, this duplicates the obviate map for single method obviation. Another problem with on the fly approach is that for an error, the error is muddled or obfuscated.

For a conflicting error of a single obviate with a multiple obviate overlap--the error is limited to being reported as a Boolean true or false. In the parser, the semantic error is reported as a semantic error of duplicate obviate declaration if the method used to add the obviate returns a Boolean true; the error can not be a more specific error of conflicting method obviate declaration.

Semantic Implementation of Method Obviate Declarations

Summarizing, on the fly obviate method declaration check is possible, yet leads to both muddling of an error report, and duplicate information in the compiler. On the fly has far too much of a cost to be used. Later, after the first semantic pass, before the second semantic pass (or as the first stage of the second pass...) the obviates are unique for each kind, but then each can be checked against the other for overlap and a more informative error message given--without an extra map data structure.

It also occurred to me that the first semantic pass in tandem with parsing is to ensure that unit elements are unique in context -- overlaps in method obviates are a semantic constraint checked before the second semantic phase is performed.

For the second semantic phase, the Context object that contains the symbol table and the Store of Mynx sentences is passed to a class which will perform the semantic analysis. It is in that class in the second phase of semantic checks that the method obviates are checked for being mutually exclusive. One for all, all for one, and none for all is one...whatever that means or could mean.