Mynx Copy Own - Automatic Copy of a Parameter

As I implement the semantic checks (and its a slow process that often is compounded because I often consolidate or find generalizations to other sentences in Mynx) and eliminate the ‘own’ method in a virtual class, or basically a static method in an interface, the original own feature and semantics struck me.

Originally, ‘own’ was the fifth parameter passing mode, basically a non-null in parameter mode, but as a local copy. Hence the original object instance passed would not be changed, but its information and state would be passed.


public void doOwnParameter(in Ordinal ordVal, own myInstance) is
    //...class implementation...
end doOwnParameter;


Calling the method:


object.doOwnParameter(first,second);


I removed the own parameter mode as feature from the original Mynx parameter passing mechanism because I originally envisioned it being implemented automagically in the high-level code -- but it was fraught with difficulty.

I saw serializing an object, then restoring its state to the prior state, or an automatically created deep copy method. However, neither is realistic for a sufficiently complex class. Serialization would require the classes of instance objects (and the classes aggregated together to compose the class of the instance, ad nauseum...) to be serializable, and that then begs the question of the native platform binary, native platform XML, or a Mynx-specific serialization.

An automagically created deep copy method is possible, but it would require such a method in every class...the same problem ad nauseum of the serialization approach. Generating a deep copy method is more feasible, but it would require every tangible, non-static class (default, constant, generic) to have the internal implicit deep copy method. Then two issues arise from the solution:

1. If a class has no copy method, no problem. But if a class has a copy method that is different in implementation from the automatically generated one, which is to be used?

2. For a generic class, how do you implement the deep copy for the generic class, and how does it work when the generic class is bound to a type both locally within the class, and globally externally.

The solution to the infinite ad nauseum copy method with an implicit deep copy method creates another difficult decision.

Like the Hercules in the battle with the Hydra which lived in the swamps near to the ancient city of Lerna in Argolis in Greek mythology, cutting off one head (solving a problem) only leads to one more growing in its place.

At the time, the solution was to remove the own parameter feature from Mynx. After all a class designer can use a covariant copy method, and override the protected copy method “VObject copy;” polymorphically.


virtual class VObject is
    protect covariant VObject copy;
end class;


A sub-class of VObject then defines a public copy method...


constant class myObject as VObject is
    public covariant myObject copy is
        //...implement copy method...
    end copy;
end class;


Then substitute a call to the “copy” method for the method call -- and voila, own parameter functionality -- although explicitly by the class designer/software developer.

Rewriting the example method:


public void doOwnParameter(in Ordinal ordVal, in myInstance) is
    //...class implementation...
end doOwnParameter;


Calling the method:


object.doOwnParameter(first,second.copy);


Now, as I implement semantic checks, including parameters for methods, constructors, and if present, a destructor, a feature from C++ - the copy constructor, struck me. I had learned and used the C++ copy constructor as part of the trifecta of assignment operator, copy constructor, and destructor. The C++ copy constructor is used for value parameters -- and likewise, in Mynx, can be used for own parameters.

Essentially a class designer must implement a copy constructor or even copy method if an own parameter is to be used with the class. The semantic check is an external one of the class interface, if an own parameter is used, check the class type interface for a public copy constructor or alternatively copy method. Then the code generation will create the appropriate high-level implementing code to create and pass a copy in the invocation using the copy constructor or copy method.

It is interesting how other languages, such as C++ which is a different programming language from Java/C# can have the solution to a language design problem. Of course, the own feature is still out of Mynx, but later I might incorporate the own feature back to the language. But adding a new feature will cause retroactive changes in the scanner, parser, and semantic checks...and it is easier to add a language feature later than to take it out...so for now copy own is a future possibility.

Own Out of the Mynx Programming Language

The original design of the Mynx programming language has an ‘own’ method in a virtual class - a way of specifying a static method in the equivalent of a Java/C# interface.

An example of an own method in a virtual class:


virtual class VInteger is

     public own VInteger parse(in String);

     //other integer methods...

end class;


An implementing class of the VInteger class with an own method is:


default class Integer as VInteger is

     public static VInteger parse(in String str) is
         //...implementation blah...blah...blah
     end parse;

end class;

Any class that implements the virtual class VInteger must implement a static method parse that returns a VInteger type object.

In principle, a very useful feature - but there is a problem. Consider the following Mynx code fragment:

Integer int to null;
VInteger vint to null;

vint as Integer(“22”);

int is VInteger.parse(“0”); //error - VInteger has no implementation
int is Integer.parse(“0”); //ok - Integer has implementation

The problem with an own method is that while a developer can specify a static method in the implementing class by a virtual class, there is no way to access the static method through the virtual class -- the virtual class allows access to instance elements, not static.

There is another nuance to the own method, presuming access to a static method through a virtual class. The Mynx code fragment:

Int32 int32 to 32; //implements VInteger - including own method
Int64 int64 to 64; //implements VInteger - including own method
VInteger vint to null;
Integer int to null;

int is VInteger.parse(“0”); //VInteger is null - but static method,
//so can invoke-?? ambiguity

vint is int32; //Int32.parse == VInteger.parse
vint is int64; //Int64.parse == VInteger.parse

The nuance of the problem is that to use a static method, it needs an instance which mixes static and instance semantics. The second wrinkle is that each static method is used instead of one, so there are multiply different static methods -- just like an instance. The third is simple that if the virtual class name refers to a null, there is no reference for the instance, nor is there for the static reference. The fourth is if a virtual class references two different instances (such as int32 and int64), which static method does it refer to -- some ambiguity.

The underlying semantic flaw is the own method is a feature but a property that does not have a larger semantic entity. Without a larger semantic entity, the instance semantics are intermixed with static semantics.

Hence, the feature is interesting, but because of the problematic nature of the feature, it will be removed from the Mynx language.

As an author and writer, I think of the words of E.B. White "The best writing is re-writing." The same applies equally in programming language design -- re-design. More emphatically, author Mario Puzo: "Rewriting is the whole secret to writing" (Time, 28/8/78) -- restated "Language design is re-design."