Still Yet Another Idea"TM"...

[Chad Slaughter]

Hello,

Thought I'd add a couple more comments to the mix.
I have three basic ideas I want to pass along, the most
important one is number 3, so you can skip the first two for now. =)

-1-
There has been some suggestion going on that because the Java
language has a feature, then so must NetRexx.  I disagree strongly with
this.  NetRexx is not the Java Language; nor is it short hand for
that Java language.  It is a simple concise language for accessing the
Java Class Library(api) and the Java virtual machine.  Beyond that the
Java Language and NetRexx are not related. (and that the reference
version of NetRexx translates to it, but that isn't necessary)
Personally, I use NetRexx so I don't have to learn, yet another poorly
written language.

-2-
Also, I would like to point out, contrary to what people might think,
you can write inner class with NetRexx.   Now you can't access
inner classes generated with Sun's javac, but you can rewrite Java code that
uses inner classes into NetRexx with easy.  If you don't believe,
I have few thousand K of Swing examples you can see. =)

-3-
Since, the main issue with inner classes is scope, according to how
I read the spec, then it seems we should simply modify NetRexx's scoping
rules, instead of its syntax rules.
I think the idea of inline/nested classes to be horrible, and quite contrary
to the philosophy of NetRexx.  So the idea of new keywords and other
nested type syntaxes is horrible, IMNSHO.  =)

But since you still want the scoping capabilities of inner class a
mechanism to place a given class into the proper scope is needed.
Luckily the mechanism and the keyword exist.  The "package" keyword can
be used to scope a class at the "inner" class level, just as is scopes
a class at the package level.  

Reasons:
1)  It causes no change in the existing language,only the rules of scoping
    and property/method access.
2)  The semantics of the language remain relatively constant.  The package
    statement still defines a scope in which the currently defined
    class has special privileges.
3)  The work of implementing this new structure lies in the hands of
    the implementer, with little or no effort on the part of
    the user needed.

The ramifications of this are that all inner classes for a given classes,
need to be defined in a separate file, as only one package statement per
file is allowed.  There are several arguments against this(that I can
think of off the top of my head), but they are more stylistic then functional.

Any comments? =)

Later,

--
Chad Slaughter  -- slaught at umr.edu
<PGP public key available upon request>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>