Dialects

Whatever you do, don't flame me.

You see, I am an amateur, never did "profession al" things. So I am
interested in things pros aren't worried about.

If there are things already out there meeting my expectations... let me
know. Best if they are free.

The 'generic' feature is debatable---but I don't quite get it. I mean,
to me, there is nothing to complain about. May be because I don't see
the complications.

But I reckon there are features, mostly already implemented in other
languages, that could improve the usability of Java. But such features
at random could harm the original motivations behind Java.
Mostly...the 'everything is a class' one. Well, not everything,
perhaps.

The key characterizatio n of the features I want is that the JRE should
not, in any way, be changed to implement them. I don't think even the
compiler should be either. So what I am proposing is not any inherent
change in the language...just adding another layer on top of Java. It
should not be called a language...I suppose it can be called a
dialect.

I suppose the generic feature is exactly what I am talking about. Even
the compilations... as far as I get it...are not necessarily anything
new. The thing is, the generics are just Objects, and the compiler
merely makes sure that the castings are according to the programmer's
prescription, all the time.

This is like constraining a language a bit. I like the sound of it.

So why don't we, if it hasn't been already done, develop standard
dialects of Java, along with 'semicompilers' that produce Java source
code? Obviously the IDEs won't help us...but what do you say?

There are things like the 'with' keyword in Visual Basic. Usually when
you use some specific object exclusively, you also don't want
interruptions right then. So a legitimate candidate could be the
'synchronized' keyword.

class Scale extends Vector<String> {
public static CMajor() {
synchronized(ne w Sequence()) {
.add("C");
.add("D");
...
.add("B");
return .this;
}
}
}

Note this way you have to name fewer variables. That's good practice.

Then there are enumerations. I think they are only good when they can
be used with the 'switch' statements as well. The C++ (and like)
implementations use integers as enums, I don't quite like it.

*The* implementation of an enum should be:

class Coin {
private Coin() { }
public static final Coin Dime = new Coin();
public static final Coin Nickel = new Coin();
....
}

We can, perhaps, add a keyword in our dialect: enumeration;

public class Something {
enumeration Coin { Dime(), Nickel(), ... };

....

public void choose(Coin coin) {
switch(coin) {
case Dime:
case Nickel:
...
}
}

And the implementation is like an inner class. I believe that the
dialect should always implement it as an inner class. The switch
implementations are just

if(coin == Dime) {
} else if(coin == Nickel) {
} ...

and perhaps, in one non-standard version...we could implement the
ordered pairs, and n-tuple in general.

(int, int) divide(int what, int by) {
int quotient = what / by;
int remainder = what - quotient * by;
return (quotient, remainder);
}

things like that.

So what do you say? Any new ideas? Perhaps a couple of more thought of
features could make the dialect worthwhile. Cheers.