Re: Argument scope
On 12/1/2010 11:42 PM, Stefan Ram wrote:
Here is an idea for a new scope in Java (could be
used in other languages as well):
void fill
( final int color
{ final int RED = 1;
final int GREEN = 2;
final int BLUE = 3; })
{ /* ... */ }
Now one can call this as, for example:
fill( GREEN );
But one does not need to write
fill( Class.GREEN );
or so anymore.
The scope of the identifier ?GREEN? is only the
argument expression corresponding to the parameter
?color?. So GREEN is not recognized here:
final int i = GREEN; fill( i ); /* not supported */
If ?Beta? is an interface, one can also write:
void fill( final int color import Beta ){ /* ... */ }
, to ?import? the constants of the interface Beta for
this purpose.
Or, we could have an import for Enum types:
void test( final enum Day import ){ /* ... */ }
, so that one then can write
test( MONDAY )
instead of
test( Day.MONDAY )
.
in certain other languages, this is closer to the default behavior for
enum...
enum Color { RED=1, GREEN=2, BLUE=3 };
Color x;
x=RED;
with the compiler essentially figuring out what was meant by this
(nevermind a few semantic subtleties here...).
now, it may come as a bit if controversy here, but there are many common
tasks which prove a bit more awkward in Java than in its main
competitors (C, C++, C#, ...).
ability to most easily and efficiently express ideas is not one of the
high points of the language.
not that it is all that bad, but in a few ways they took the "thow the
baby out with the bathwater" strategy to language design (IOW, throwing
out many language features deemed "complicated" or "unsafe" at the cost
of making the language more awkward to use), and then tried apparently
to build elaborate class libraries to try to mask over some of the
weaknesses in the core language.
now, in everything there are costs and benefits...
yes, C is a little crufty, and many practices traditionally associated
with it are a subject of criticism (such as aversion to GC, or
overuse/abuse of pointer arithmetic, or for that matter coding practices
that don't scale well). these are not, however, inherent in the language.
yes, C++ is absurdly complex...
and yes, C# is mostly just a Java knock-off with some more C++ style
syntax and semantics reintroduced (nevermind traditional C-style
features re-introduced in different ways, such as via 'delegate' and 'ref').
I am torn at times...
I like the power of expression and fine level of control of C.
I like some of the added abstraction over the system of Java (and VM
architecture has some merits, although I disagree some with the
traditional overall architecture of the JVM).
I personally feel C# is a well designed language, but admittedly, I have
less warm and fuzzy feelings about .NET in general. (for my uses, .NET
was theoretically better, but I suspect more practically would have been
a worse investment).
ok... I am not so much of a fan of C++ though, its only real merit being
that it is close to C and has a good feature-set, but is at the same
time also a complex mess of cruft which I would rather not bother with
so much.
I guess this is why, although probably in the end somewhat pointless, I
tend to end up implementing my own compilers, languages and pieces of VM
technology.
even if implementations are only half-assed, at least I can do them my way.
although, I also tend to prefer trying for compatibility and standards
conformance where possible/reasonable, as in the end, the world already
has too many "YetAnotherLanguage" running on "YetAnotherVM" setups...
little is gained by more of the same...
hence, the current use of JVM architecture as a base.
and even if in the end all this is pointless and no one cares or
benefits, really why does this need to matter?
or such...