Another shot at inner classes :)

[dIon Gillard/Multitask Consulting/AU]

Ok, this is a change to my original suggestion. The new suggestion is to
add 2 new keywords: inner and nested to the class statement. Bother of
these keywords take an optional class name, i.e.

class [name] [inner [class1]] [nested [class2]]

if the class1 or class2 entries are left out, they are implicity the
previously defined class.

This removes the need for 'end [optionalName]' and is still useful in the
java sense, without introducing blocks of code that return objects (other
than methods) or methods that implement classes.

Inner vs Nested is pretty well documented in Sun's tutorial. I've thrown
out the idea of anonymous classes, as *I* think they're a bad design idea.
Inner classes need an instance of the outer class (i.e. are NOT static in
the java declaration). Nested classes are static in the java declaration.

This discussion has been good, as it's helped me see some of the hassles
inner classes cause people :)


Examples
==========================================================

[dIon Gillard/Multitask Consulting/AU]

At 08:55 18/01/98 +1100, dIon Gillard wrote:
>Ok, this is a change to my original suggestion. The new suggestion is to
>add 2 new keywords: inner and nested to the class statement. Bother of
>these keywords take an optional class name, i.e.
>
>class [name] [inner [class1]] [nested [class2]]
Let me make that:
class name [inner | nested]

The changes here mean:
        1. All inner or nested classes must have a name
        2. A class can be 'top-level', inner or nested. Mutually exclusive.
        3. No naming of the class on the inner or nested class: Inner and nested
classes must follow their outer class in the code.

So far, I haven't really come up with a syntax for inner classes accessing
their 'outer' class...Java uses Outer.this, where 'Outer' is the outer
class name. I'm half tempted to just leave this....

dIon Gillard
Sun Certified Java 1.1 Programmer
Work: http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/netrexx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>

[Martin Lafaix]

> From: "dIon Gillard" <[hidden email]>
> >Ok, this is a change to my original suggestion. The new suggestion is to
> >add 2 new keywords: inner and nested to the class statement. Bother of
> >these keywords take an optional class name, i.e.
> >
> >class [name] [inner [class1]] [nested [class2]]
> Let me make that:
> class name [inner | nested]

I very much prefer your new shot :-)

But don't you mean:

  class name [inner [class1] | nested [class2]]

[There's a need for class1 and class2, as a class can have more
 than one inner/nested class and an inner or nested class could
 also include inner/nested classes.]

Not that it convinces me of the need of inner/nested class in
NetRexx, though :-)  (I have nothing about adding new features.
They just have to be useful...)


Martin
--
[hidden email]
Team OS/2
http://wwwi3s.unice.fr/~lafaix/os2.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>

[dIon Gillard/Multitask Consulting/AU]

At 11:23 18/01/98 +0100, you wrote:

>
>> From: "dIon Gillard" <[hidden email]>
>> >Ok, this is a change to my original suggestion. The new suggestion is to
>> >add 2 new keywords: inner and nested to the class statement. Bother of
>> >these keywords take an optional class name, i.e.
>> >
>> >class [name] [inner [class1]] [nested [class2]]
>> Let me make that:
>> class name [inner | nested]
>
>I very much prefer your new shot :-)

Glad to hear it :)

>But don't you mean:
>
>  class name [inner [class1] | nested [class2]]
nope....I realise that you can't have more than one level of nesting with
my above syntax, i.e. No Fred.Topping.Styles class.

>[There's a need for class1 and class2, as a class can have more
> than one inner/nested class and an inner or nested class could
That would be handled by another nested/inner declaration. They would
always associate with the previous top-level class.

> also include inner/nested classes.]
Hmmm....I didn't want to add nested-nested-... classes, but with the
readdition of the optional class keyword, it is possible.

>Not that it convinces me of the need of inner/nested class in
>NetRexx, though :-)  (I have nothing about adding new features.
>They just have to be useful...)

How about adding further granularity to scope?
Implementing closures?
For easy code generation?
Providing a stronger separation of responsibilities?

dIon Gillard
Sun Certified Java 1.1 Programmer
Work: http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/netrexx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>

[Martin Lafaix]

> From: "dIon Gillard" <[hidden email]>

Well, another suggestion:

CLASS outer.name [NESTED]

(or maybe INNER instead of NESTED, depending on which usage is
 used less frequently.  'outer' being the name of the class
 containing the one we are defining.)

It's always possible to differentiate this usage from the
currently accepted one.

So it would give something like

  class fred
    ...

  class fred.topping
    ...

  class fred.topping.style
    ...

Since 'fred.topping' and such is the name used to reference such
classes, it seams quite logical to reuse...

> How about adding further granularity to scope?

Packages are fine for this purpose, don't you think?

> Implementing closures?
> For easy code generation?

If by 'easy code generation' you mean 'user-written' code, well,
yes with closures (but not with nested classes) but with a high
price to pay (aliasing, obfuscation and such).

If you mean 'generated' code, well, I think it's a non-issue.  A
programmer has a right to be lazy.  A compiler or code generator
implementer has not! :-)

> Providing a stronger separation of responsibilities?

Packages does this even better, by forcing you to use separate
files.


Martin
--
[hidden email]
Team OS/2
http://wwwi3s.unice.fr/~lafaix/os2.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>

[dIon Gillard/Multitask Consulting/AU]

At 22:36 18/01/98 +0100, Martin Lafaix wrote:
>
>> From: "dIon Gillard" <[hidden email]>
>
>Well, another suggestion:
>
>CLASS outer.name [NESTED]
One thing...to keep line numbers ok for Java/NetRexx in debug output or
compiling, there couldn't be another top level class between an outer class
and an inner class.

>(or maybe INNER instead of NESTED, depending on which usage is
> used less frequently.  'outer' being the name of the class
> containing the one we are defining.)
>
>It's always possible to differentiate this usage from the
>currently accepted one.
>
>So it would give something like
>
>  class fred
>    ...
>
>  class fred.topping
>    ...
>
>  class fred.topping.style
>    ...
>
>Since 'fred.topping' and such is the name used to reference such
>classes, it seams quite logical to reuse...

I like this....

>> How about adding further granularity to scope?
>
>Packages are fine for this purpose, don't you think?
Nope...each class in a package takes up a name in the global namespace -
and causes sill naming conventions. Like JComponent....

>> Implementing closures?
>> For easy code generation?
>
>If by 'easy code generation' you mean 'user-written' code, well,
>yes with closures (but not with nested classes) but with a high
>price to pay (aliasing, obfuscation and such).
What aliasing and obfuscation is involved in inner classes? Do you mean the
Outer$Inner naming?

>If you mean 'generated' code, well, I think it's a non-issue.  A
>programmer has a right to be lazy.  A compiler or code generator
>implementer has not! :-)
And the programmer writing the compiler or code generator? :)

>> Providing a stronger separation of responsibilities?
>
>Packages does this even better, by forcing you to use separate
>files.
Separate files? By this I was referring to the Enumerator example from
previous posts...in that case, the non-inner class solution was all in one
file.

dIon Gillard
Sun Certified Java 1.1 Programmer
Work: http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/netrexx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>

[Martin Lafaix]

[If this discussion bores you, beloved reader, please let me/us
 know.  We don't have to clutter this list if we are the only
 ones interested :-)]

> From: "dIon Gillard" <[hidden email]>
> One thing...to keep line numbers ok for Java/NetRexx in debug output or
> compiling, there couldn't be another top level class between an outer class
> and an inner class.

The fact that the current reference implementation (the only one
available, granted :-) uses a javac pass should not influence the
design of NetRexx.

> >Packages are fine for this purpose, don't you think?
> Nope...each class in a package takes up a name in the global namespace -
> and causes sill naming conventions. Like JComponent....

But in this very case inner (or nested) classes would have been of
no help...  Nested classes does not offer the ability to use
'short' names from outside of their scope, which is one of the
benefits of packages.

> What aliasing and obfuscation is involved in inner classes? Do you mean the
> Outer$Inner naming?

The fact that you use the same notation for accessing your own
members or an outer class member.  A typo can generate very hard
to track bugs (by leading you to think you are accessing a
'local' member when in fact you are accessing an 'outer' one ---
or the opposite).

> And the programmer writing the compiler or code generator? :)

...as a right to be lazy, too :-)  But the product he/she writes
has to do as much work as possible.  As an example, I think it's
up to the compiler programmer to worry about the quality of code
the compiler produces (in term of speed/size/...).  The 'laziness'
I'm talking about is the right to use the adequate tool to
simplify your work.  Such as using NetRexx instead of Java :-)

> >> Providing a stronger separation of responsibilities?
> >Packages does this even better, by forcing you to use separate
> >files.
> Separate files? By this I was referring to the Enumerator example from
> previous posts...in that case, the non-inner class solution was all in one
> file.

Yes for the Enumerator example (but I don't find this example to
be a significant enhancement over the other solution).

A little thing I find instructive about nested/inner classes:  in
the 3 examples provided in the specs, the first one is solved as
least as elegantly with NetRexx's 'adapter' classes, the second is
(as stated in the specs, even :-) a flawed one in the sense it
brings nothing and the third one, while correct, again brings very
little (if at all) compared to the solution defining another
class.


Martin
--
[hidden email]
Team OS/2
http://wwwi3s.unice.fr/~lafaix/os2.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>