Monday, March 4, 2019

Moving Upward in Java Syntax--Having a Tiger by the Tail

ZeptoN is intentionally designed to be fully compatible with Java syntax--but eliminating the class constructor and some other features...like constructors, modifiers for access, extends and implements. This is from the addition of the “prog” or program construct.

Originally I opted for the Java 1.1 syntax, and then was incorporating later features--such as enums, static import, and so on. But then in going through the syntax of Java, I realized it would be easier to user a later, more sophisticated Java syntax, and remove features from syntax.

I opted for the Java 1.5 syntax, Java “Tiger” because it has features I want included in Zepton...such as inner classes, enumerations, static imports. One feature I have removed is annotations--that’s for a more savvy, sophisticated user, and when constructing classes for re-usable functionality.

Zepton is for those learning to program and for those that want to quickly codify a solution to a problem using Java style syntax and concepts. The appeal is on both ends of the software development continuum--new users moving along the continuum, and for advanced users that need a method to write a program quickly using Java.

That is one major design flaw of Java--the lack of a simple program construct. This is almost Pascal in reverse, Pascal had a great program construct, but then was weak in providing a mechanism for reuse and libraries without extending the language in a non-standard, proprietary way--such as Turbo Pascal.

The difficulty is with Java features for classes, some are easy to remove--such as generics (no need for generics in a program) whereas others can require some thought (annotations are great, but for the two kinds of users not really relevant), but others can be useful such as inner classes, enumerations.

For a static block, that’s a more complex question, since a program is not a class so not loaded unless re-run. A static block is a means to ensure initialization and default behavior before a constructor is called to create an instance--but there are no instances and no constructor calls since the program is not a class.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.