The Defacto Defaults of the Mynx Class Default Method

Concept of Default Method

A Mynx class can specify a default method--a method that is invoked implicitly on an instance, when the instance is used--like a constructor or destructor.

For example:

    x = y;

By operator overloading, the = operator is the method 'set':

    x.set(y);

The variable y is an instance of some class, but it would invoke a default method if one is declared in the class. Implicitly, all instances return a reference to the instance, or something like:

    public myClass me is
        return this;
    end me;

However no me method is actually defined, but it is equivalent in operation. So in effect, all instances have a default method.

Thus the code could be re-written in the most explicit syntax of:

    x.set(y.me);

Syntax of a Default Method

Originally a default method had the BNF of:

    DEFAULT := ACCESS default is to [null|ID] ';'

But after some consideration and contemplation with use cases, it seems inefficient for two reasons:

1. The default method is invoked implicitly, so is always visible thus the access is always public.


2. The default method of being to null is a do nothing operation, but that is contradictory to even the implicit default method which returns the instance reference.

Altering the sentence prefix and suffix for partitioning (the compiler phase before syntax analysis in sentential parsing) and the parser for the default method sentence, the syntax in the revised Extended Backus-Naur Form (EBNF) for Mynx is:

    DEFAULT := default is to ID ';'

Unlike a destructor which can be private or protect in visibility, the default method if defined is visible--it cannot be invoked explicitly, so must be visible to invoke it exists. The to null is removed, but if a software developer's intention is to do nothing, the method it is referring to can do nothing.

Some other semantic rules for a default method are:

1. The default method cannot be static - must be a stateful method, an instance method.


2. The default method is a function not a procedure; the default method returns something.


3. The default method must be public method in the class to avoid implicit circumvention of the external class method visibility.
   

Example of Use of a Default Method

A default method is primarily syntactic sugar, i.e. it is used to make code more clean and elegant (if such a thing as elegance is possible...). For example, for a two-dimensional array with the following expression-assignment statement:

    x(2,3) = x(3,2);

The default method is the at method, which returns the particular type stored at that position. Substituting the explicit for the implicit method call:

    x.at(2,3) = x.at(3,2)

And the operator = is overloaded in the Int class as the set method. Substituting that in place of the operator:

    x.at(2,3).set(x.at(3,2));

The original code is syntactically neat and clean, whereas the actual full method invocation expression is not as elegant.

A class Array2DInt would define a method in a class:

constant class Array2DInt is

    public constant Int at(in Ordinal x, in Ordinal y) is
        !! define the method !!
    end at;

    public default is to at;

end class;

Conclusion

The default method of a class has specific semantics, but is like an operator overload, association of an operator with a method. In the case of a default method, it is overloading a class instance for a class type with an implicit method.

If a class does not explicitly define a default method, the implicit default method or action is to get the instance reference of the class.

Does Mynx Got MOXI or MOBI -- External Semantics of other Class Types

The first phase of the context semantic checks is complete--the uniqueness check for unit (class or program) elements. The next step is to do the context semantic checks that are specific to a Mynx class or program, and existence check--the TEAC (type existence, annotation, compatibility). The existence is both internal (declared in context or declared before use in a method) and external semantics--the class as a type exists in a external semantic information file.

MOXI Concept

Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.

The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.

MOXI Implementation

A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.

The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.

MOBI File

The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.

MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.

The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.

MOXI Requirements

A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.

1. Attributes within a tag in alphabetic order.


2. Major element blocks in alphabetic order within CLASS block.


3. Major blocks always use start/close tags with count attribute--even when empty.


4. Default and destruct are empty tag.


5. outer block is a MOXI block, inner block is CLASS block.

This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.

An example structural fragment of a MOXI file:

<moxi version=''>
  <class mode='' module='' name=''>
        
    <attributes count=''>
      <attribute ... />
    </attributes>

    <constructs count=''>
      <construct ... >
        <args ... >
          <arg ... />
        </args>
      </construct>
    </constructs>

    <default />
    <destruct />

    <methods count=''>
      <method ... >
        <args ... >
          <arg ... />
        </args>
      </method>
    </methods>

    <overloads count=''>
      <overload ... />
    </overloads>

    <superclasses count=''>
      <superclass .../>
    </superclasses>        

  </class>
</moxi>

MOXI Query for Semantics

Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.

However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.

The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.

The IQueryMOXI interface and the underlying MOXIObject implementation. For now, the types are checked for external existence from internal existence in a declaration.

A specific check for a method, attribuBlog Does Mynx Got MOXI or MOBI -- External Semantics of other Class Types
February 2008

The first phase of the context semantic checks is complete--the uniqueness check for unit (class or program) elements. The next step is to do the context semantic checks that are specific to a Mynx class or program, and existence check--the TEAC (type existence, annotation, compatibility). The existence is both internal (declared in context or declared before use in a method) and external semantics--the class as a type exists in a external semantic information file.

MOXI Concept

Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.

The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.

MOXI Implementation

A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.

The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.

MOBI File

The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.

MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.

The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.

MOXI Requirements

A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.

1. Attributes within a tag in alphabetic order.


2. Major element blocks in alphabetic order within CLASS block.


3. Major blocks always use start/close tags with count attribute--even when empty.


4. Default and destruct are empty tag.


5. outer block is a MOXI block, inner block is CLASS block.

This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.

An example structural fragment of a MOXI file:

<moxi version=''>
  <class mode='' module='' name=''>
        
    <attributes count=''>
      <attribute ... />
    </attributes>

    <constructs count=''>
      <construct ... >
        <args ... >
          <arg ... />
        </args>
      </construct>
    </constructs>

    <default />
    <destruct />

    <methods count=''>
      <method ... >
        <args ... >
          <arg ... />
        </args>
      </method>
    </methods>

    <overloads count=''>
      <overload ... />
    </overloads>

    <superclasses count=''>
      <superclass .../>
    </superclasses>        

  </class>
</moxi>

MOXI Query for Semantics

Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.

However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.

The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.

The IQueryMOXI interface and the underlying MOXIObject implementation. For now, the types are checked for external existence from internal existence in a declaration.

A specific check for a method, attribute, or operator is next, driven by the need to do it as part of the Mynx compiler.