Mynx's Plethora of Classes - minus one or two...
In a discussion group, it was pointed out that Mynx has a plethora of classes, which can seem confusing. This got me to thinking, but then I realized its more that I do not have a good rationale discussion in the Mynx manual. Part of the Mynx manual is to elucidate on the how's and why's of Mynx.
The two class types are defined and not completely defined, or abstract and non-abstract. The non-abstract have instance versus class classes. This breaks down into the three core kinds of classes.
Mynx has 3-core class kinds:
1. abstract - incompletely defined
2. instance - completely defined, but instances (create objects)
3. static - completely defined, but no-instances (one existing class)
The last two types of classes, instance and static also have a restriction on sub-classing, using inheritance to create a sub-class. The abstract classes are sub-classable by the nature of being abstract.
1. abstract
a. virtual - completely abstract
b. abstract - partly abstract, some methods defined
c. generic - least abstract, only type is abstract
2. instance
a. default - completely defined, sub-classable
b. constant - completely defined, non-sub-classable
3. static
a. static - completely defined, sub-classable (by static)
b. singular - complete defined, non-sub-classable
It can seem wierd that a static class is inherited, but in the case of non-instantiable, or stateless functionality, specialization through inheritance might be needed.
For example, a general Platform.mynx class might have generalized functionality, but a UnixPlatform.mynx or WinPlatform.mynx might then provide more specific functionality--then the UnixPlatform.mynx could be extended to LinuxPlatform.mynx to access Linux-specific functionality -- all with a static class, without instances.
One type of class (maybe include later in the future) was a "scatter" class - a class that is scattered across different systems on a network. This is similar to the C# 2.0 partial class - create a distributed class design. I opted not to, because it adds a level of complexity, and the primary goal is to get Mynx up and running.
I mention the "functor" class in a previous blog post -- a class that is a method. That too is a possibility for the future. If seven classes were confusing, imagine nine, or variants on those nine, such as a generic scattered class. Lions, tigers, and bears -- oh my!
The two class types are defined and not completely defined, or abstract and non-abstract. The non-abstract have instance versus class classes. This breaks down into the three core kinds of classes.
Mynx has 3-core class kinds:
1. abstract - incompletely defined
2. instance - completely defined, but instances (create objects)
3. static - completely defined, but no-instances (one existing class)
The last two types of classes, instance and static also have a restriction on sub-classing, using inheritance to create a sub-class. The abstract classes are sub-classable by the nature of being abstract.
1. abstract
a. virtual - completely abstract
b. abstract - partly abstract, some methods defined
c. generic - least abstract, only type is abstract
2. instance
a. default - completely defined, sub-classable
b. constant - completely defined, non-sub-classable
3. static
a. static - completely defined, sub-classable (by static)
b. singular - complete defined, non-sub-classable
It can seem wierd that a static class is inherited, but in the case of non-instantiable, or stateless functionality, specialization through inheritance might be needed.
For example, a general Platform.mynx class might have generalized functionality, but a UnixPlatform.mynx or WinPlatform.mynx might then provide more specific functionality--then the UnixPlatform.mynx could be extended to LinuxPlatform.mynx to access Linux-specific functionality -- all with a static class, without instances.
One type of class (maybe include later in the future) was a "scatter" class - a class that is scattered across different systems on a network. This is similar to the C# 2.0 partial class - create a distributed class design. I opted not to, because it adds a level of complexity, and the primary goal is to get Mynx up and running.
I mention the "functor" class in a previous blog post -- a class that is a method. That too is a possibility for the future. If seven classes were confusing, imagine nine, or variants on those nine, such as a generic scattered class. Lions, tigers, and bears -- oh my!
Labels: abstract class, class rationale, default class, instanceof Java, Mynx classes, static class

