Mynx Constructor and Destructor Separating Definition from Reference

The original design of the Mynx super-class and this-class semantics for a constructor and destructor used super.construct, this.construct, and super.destruct. (Note: this.destruct is a semantic contradiction, as only one destructor is defined so no need to define additional destructor that is semantically erroneous, and self-reference would be infinitely recursive.)

Problems of Mynx Constructor, Destructor Design

The syntax as designed had the problem of ambiguity in reference for constructors, and with the destructor explicit semantics which are redundant and contradictory. Both indicate that the solution can work, but it is not the best solution--a solution without those problems is clearly better.

Using a reference to the destructor is also explicitly calling the destructor -- and the destructor, like the constructor is never invoked explicitly. The only minor variant is that the constructor is referenced in definition of another constructor -- either within the same class, or in the super-class.

Constructor Reference

 class X is
 
  public construct is to this.construct(0);
 
  public construct(in Int i) is
   ...constructor definition
  end construct;
 
 end class;

Constructor Ambiguity of Reference by Keyword

This approach works for constructor reference within the class. But a super-class reference is not so neat and clean.

 class A as X,Y,Z is
 
  public construct is to super.construct;
    
 end class;

If only one of the super-classes has a null constructor, then the constructor is clearly unambiguous. But in the case of more than one null constructor creates ambiguity, which super-class constructor is being used to define the class constructor? Constructors are not inherited, so a super-class constructor cannot be disambiguated as the class’s own constructors. Remember, ambiguity is the source of uncertainty that creates problems in a programming language. The solution to constructor and destructor semantics creates ambiguity so it is problematic at best, unworkable in the least.

Explicit Constructor Reference by Name

Constructor reference is explicit both within and without a class.

Explicit Constructor Inside a Class

A constructor is distinguished in definition in contrast to a constructor reference. The important feature is that a constructor definition uses ‘construct’ keyword and a constructor reference uses ‘this’ keyword.

 class X as A,B,C is
 
        //this keyword to reference a constructor
  public construct is to this(0); 
 
        //construct keyword to define constructor
  public construct(in Int i) is   
   ...constructor definition
  end construct;
 
 end class;

Using the ‘this’ keyword makes the intent, constructor definition versus constructor reference more explicit. The simplification of using the ‘this’ keyword instead of this.constructor is a nice simplification.

Explicit Constructor Outside a Class

Constructor reference outside a class to the super-class is the source of ambiguity. It is appropriately expressed in the form of a question (start counting down from 30-seconds to 0-seconds with catchy elevator music playing in the background...) as “How do you clearly refer to a super-class constructor?”

The syntax of super.construct(...) is inadequate, but adding the class name as an identifier does neatly and clearly resolve the ambiguity. So then the syntax super.construct.A(...) is explicit. But the keyword ‘construct’ is for a definition, and for a reference is redundant. A more generalized form is to use the syntax of a method call in the super-class, that of - super.(...).

 class A as X,Y,Z is
 
  public construct is to super.X; //instead of super.construct
    
 end class;

A semantic consideration is the question of how does the Mynx compiler know that the method is a constructor of the super-class and not a method? Simple, the Mynx compiler determines that the method does not exist in the super-class method list, and the class name is referenced, not a method. As a class method cannot be the class name, there is no overlap -- and the constructor definition uses the keyword ‘construct’ not the class name (as in Java, C++, C#).

In Mynx, a super-class reference to a constructor uses the class name, along with the prefix ‘super’ keyword. The super-class constructor can be clearly referenced, and the intention explicit.

The “Big Three” of C++, Java, C# use the class name as the constructor name; it is strange, but it does have the advantage that for reference to a constructor and destructor in super-classes (particularly in multiple-inheritance in C++) it avoids any possibility of ambiguity. The intention of definition versus reference is somewhat masked, but the clarity in reference is a gain.

The revised Mynx approach of distinguishing definition from reference, and using the class name to reference a constructor is much better solution than the one designed before. (Think drum versus disk brakes or piston versus turbines.)

One important semantic consideration is if a super-class constructor is referenced by a sub-class constructor, is it valid to reference a super-class constructor from a non-constructor (class method, destructor, default method)?

A non-existent class method referenced in a class constructor with a ‘super’ keyword must be a super-class constructor. If referenced in another method, is a check for a super-class constructor performed, or is it a non-existent method. The added semantic check to report a semantic error of super-class constructor reference outside of a constructor while informative, adds extra processing time. Conversely, a report of a non-existent method in a class method is misleading semantically, although less costly in terms of processing time for semantics.

Destructor Semantics Implicit

The previously designed Mynx destructor semantics were complex. The new design for the destructor semantics is for all destructors to be implicitly invoked first, before the sub-class destructor is executed. The destructor invocation is automatic, synthesized by the compiler. Each destructor is mutually exclusive when invoked, and in the order of inclusion in the class super-class list. Only destructors that are protect or public access can be invoked. The semantic constraint of not explicitly invoking a destructor is maintained. There is no keyword for explicit super-class destructor reference. The keyword ‘destructor’ is used in the definition of the one and only class destructor. For a software developer, the implicitness is a reduction in the cognitive load about explicitly invoking a destructor and referencing it.

 class X as A,B,C is
 
  public destruct is
   
   //implicit invocation of A.destruct, B.destruct, C.destruct
   null;
 
  end destruct;
 
 end class;

Modifying the Mynx Grammar

The updated Mynx grammar from version 9.3.2 to 9.3.3 is void (no pun meant). The new grammar for the re-design is Mynx EBNF 9.3.3.1. Interestingly enough, the older grammar supported the super-class reference semantics, and the implicit destructor semantics. Only one syntax production rule is modified to allow class reference within the class.