Mynx Constructor and Destructor Semantics

In implementing context semantics, and looking ahead toward sentence-method semantics (far ahead, after uniqueness are the existence semantics) one important semantic clarification (as you implement a new language, the meanings of things go from general to very specific to avoid ambiguity in the compiler implementation...although some languages are more specific than others) is in the use of constructors and destructor of a class.

Both constructor and destructor are distinct from other class methods in that they are not explicitly invoked, and neither are inherited by a sub-class from the super-class.

A destructor is invoked automatically in Java and C#, and in C++ the super-class destructors are also invoked when the class destructor is invoked (again, not explicitly but indirectly with a delete[] for instance). In Java a constructor is invoked (similar to C++ and C#) with a new, but a super-class constructor must be called explicitly. The semantics of explicitness and implicitness must be clarified and the semantic rules written in the Mynx Programming Language Manual (MPLM) the “Mynx Book” which is the language guide.

My general rule of thumb or heuristic is to avoid implicitness except where it is also possible to be explicit. An implicit default which has a converse with an explicit syntax is only half expressing a feature, the implicit feature is unexpressable.

By this heuristic the C++ feature of implicitly calling a destructor (when possible, many a memory leak from lack of the keyword ‘virtual’ or the destructor being protected or private) is a bad approach. The intention can get lost in non-existent code.

Mynx, unlike C++ and Java, does not automatically create a default constructor. The compiler will flag an error of not having a constructor in the class if one is not defined for a class that can have an instance.

In the same approach, Mynx does not implicitly call the super-class constructors or a super-class destructor. The use of a constructor or destructor in Mynx must be explicit. This raises the following points of semantics:

1. What if a super-class constructor or destructor is never used?


2. What if a super-class constructor or destructor is used?

As the Mynx constructor and destructor are never explicitly invoked by a user using the class, similarly there is a semantic constraint on using them in defining the class.

The used hints on the major point, where in a class can a super-class constructor or destructor be used? If not used, what is the potential consequence?

The latter question of non-use is a semantic error if the super-class is a concrete and non-static class. Not invoking a super-class constructor or destructor if defined can lead to class initialization anomalies, any super-class methods inherited could function inconsistently, and when the class is destroyed complete finalization anomalies. In short, if a super-class is sub-classed and the super-class is concrete and non-static, then the constructors and destructors must be used. If a super-class defines them, the sub-class must use.

The answer the the not using constructors and destructors of a super-class leads back to the former question of where can the constructor and destructor be used in a sub-class.

The answer is simple--only a sub-class constructor or destructor invokes the same in the super-class. The semantic context rule is like invokes like. This semantic constraint ensures that a constructor and destructor can never be called explicitly or used to define a method.

The semantic context rules of a constructor and destructor are like calls like, and if you have them in the super use them in the sub. One might be inclined to go for if a super-class has a destructor, the sub-class destructor first invokes all of them. But then there is the point in what order, and before the sub-class destructor code is invoked, or after, or at any point in between? Such ambiguity would have to be resolved by a Mynx implementation by the compiler writer, and create different versions of Mynx with an implicit approach to those questions.

Another heuristic of Mynx is to give the software developer choice, requiring explicitness even if it can be tedious (although with today’s software environments and tools, much of the tediousness is relieved by the tools).

A destructor defines or invokes the super-class destructor explictly. For a class with multiple super-classes it can be helpful to indicate invocation of all.

For example, invoking multiple destructors with a single invocation:

class X as A,B,C is

    //other class source code...

    public destruct is

        super.destruct; 

        //class X destructor code, close files, sockets, release memory

    end destructor;

end class;

The equivalent invocation of the destructor in the same sub-class is:

class X as A,B,C is

    //other class source code...

    public destruct is

        super.destruct.A;
        super.destruct.B;
        super.destruct.C;

        //class X destructor code, close files, sockets, release memory

    end destructor;

end class;

The software developer has the choice of invoke super-class destructors implicitly using order of inheritance, or each destructor must occur in a specific order with sub-class destructor code inter-mixed, the software developer can be explicit.