Fwd: NetRexx Minor classes (WAS: Re: FW: [Ibm-netrexx] [Enhancement proposal]: Dependent classes and access to ...)

[David Requena]

Hi All,

In my previous email I introduced an error in the code of JavaSubclassedContainerClass. I forgot I had renamed the parent class.

Here's the correct code:

class JavaSubclassedContainerClass extends ContainerClass {
   
    public JavaSubclassedContainerClass(String containerProp) {
        super(containerProp);
    }
   
    public static void main(String[] args) {
       
        JavaSubclassedContainerClass sMCT =
            new JavaSubclassedContainerClass("_prop at JavaSubclassedContainerClass");
       
        // lets check if we inherited RegularMinorClass
        JavaSubclassedContainerClass.RegularMinorClass.greet();
   
        // lets check if we inherited DependentMinorClass
        DependentMinorClass dMC = sMCT.new DependentMinorClass();
        dMC.greet();

    }

}

And while I am at it, here is here is another demonstration of the same concept from an different angle. This time in NetRexx.

Just note that reflection won't dig a hole through any access layers enforced by the java platform. In particular it won't facilitate access to unaccesable members as per the specification.

class NrxSubclassedContainerClass2 extends ContainerClass
   
    method NrxSubclassedContainerClass2(containerProp=String)
        super(containerProp)
   
    method main(args=String[]) static
       
        nSCC = NrxSubclassedContainerClass2("_prop at SubclassedMinorClassTest")

        /*
         * In a previous sample sent to the ibm-netrexx list I demonstrated
         * how the NetRexx compiler pretends that minor classes are not present
         * in subclasses of the class in which they are defined. In any case
         * the compiler doesn't allow access to them using NetRexx syntax.
         *
         * Here I'll be using reflection to prove how they're in fact present
         * and accessable.
         *
         */
       
        -- get any inner classes in our subclass
        containedClasses = nSCC.getClass().getClasses()
        numContainedClasses = containedClasses.length  -- yup! two will be found!
       
        Say '---'
        Say 'Found' numContainedClasses 'contained classes'
        Say '---'
       
        -- So they're here. Lets try to access them
        loop i=0 to numContainedClasses - 1
            do
                clss = containedClasses[i]
                -- get the class name
                clssName = clss.getName()
                -- get class modifiers
                mods = clss.getModifiers()
                -- get then greet() method if there's one
                mthd = clss.getMethod('greet', null)
               
                if Modifier.isStatic(mods) then do
                    -- if class is static, this is a regular minor class
                    Say 'Class' clssName '(static inner class)'
                    Say '\tInvoking' clssName'.greet()'
                    mthd.invoke(nSCC, null)
                    Say '\nSUCCESS: NrxSubclassedContainerClass2 inherits' -
                        'RegularMinorClass and can access it!'
                    Say '---'
                    end
                else do
                    -- else it's a dependent class (no local or anonymous in NetRexx)
                    Say 'Class' clss.getName() '(non-static inner class)'

                    -- get at the dependent class constructor
                    ctorQueryArgs = Class[1]
                    ctorQueryArgs[0] = nSCC.getClass().getSuperclass()
                    ctor = clss.getConstructor(ctorQueryArgs)

                    -- now instantiate a dependent object bound to our instance
                    -- of the subclass
                    ctorArgs = Object[1]
                    ctorArgs[0] = nSCC
                    inst = ContainerClass.DependentMinorClass ctor.newInstance(ctorArgs)

                    Say '\tInvoking' clssName'.greet() [with enclosing nSCC context]'
                    inst.greet()
                    Say '\nSUCCESS: NrxSubclassedContainerClass2 inherits' -
                        'DependentMinorClass whose instances can be bound to' -
                        'NrxSubclassedContainerClass2 instances!'
                    Say '---'
                    end
                end   
               
            catch e=Exception
                e.printStacktrace()
            end
           
            -- now check if the dependent instance we have stored in an inherited
            -- public property is in fact bound to our subclass instance
            Say '\tInvoking' clssName'.greet() [on inherited instance]'
            nSCC._dependentMinorClass.greet()
            Say '\nSUCCESS: Not only the property stores a valid reference to' -
                'a ContainerClass.DependentMinorClass. It''s automatically bound' -
                'to our instance of NrxSubclassedContainerClass2!'
            Say '---'

Unsurprisingly running this prints:

---
Found 2 contained classes
---
Class ContainerClass$RegularMinorClass (static inner class)
    Invoking ContainerClass$RegularMinorClass.greet()
Hello from RegularMinorClass
 
SUCCESS: NrxSubclassedContainerClass2 inherits RegularMinorClass and can access it!
---
Class ContainerClass$DependentMinorClass (non-static inner class)
    Invoking ContainerClass$DependentMinorClass.greet() [with enclosing nSCC context]
Hello from DependentMinorClass (parent.prop: _prop at SubclassedMinorClassTest)
 
SUCCESS: NrxSubclassedContainerClass2 inherits DependentMinorClass whose instances can be bound to NrxSubclassedContainerClass2 instances!
---
    Invoking ContainerClass$DependentMinorClass.greet() [on inherited instance]
Hello from DependentMinorClass (parent.prop: _prop at SubclassedMinorClassTest)
 
SUCCESS: Not only the property stores a valid reference to a ContainerClass.DependentMinorClass. It's automatically bound to our instance of NrxSubclassedContainerClass2!
---


-------- Mensaje original --------

Asunto:	NetRexx Minor classes (WAS: Re: FW: [Ibm-netrexx] [Enhancement proposal]: Dependent classes and access to ...)
Fecha:	Fri, 30 Jul 2010 14:52:46 +0200
De:	David Requena [hidden email]
Para:	IBM Netrexx [hidden email]

Mike,

Sorry for the late reply. I wanted to review some other aspects of minor classes prior to proceed.

El 22/07/2010 9:57, Mike Cowlishaw escribió:

David wrote: 

 

Dependent classes are not related in *any way* to inheritance. A dependent object is inextricably linked to its parent object by a totally orthogonal relation: membership.

Hmm, my bad.  The word 'dependent' just didn't sink in (and in any case I've pretty much forgotten all about them).   You may have a point :-).   However I do think calling them private and then allowing access would be confusing/likely to cause error.

Well, they could be qualified something else, say 'dependable'.
That wouldn't change the fact that the compiler would generate java code (thus, binary classes) with them qualified as private

(And raises issues of whether subclasses of a dependent calls can 'see' them, and so on.)

hmm.. I don't think so. I admit this stuff can get quite mind twisting but at any rate: if java's 'non static inner classes' are being used to implement dependent classes, then just map what java specifies for every corner case.

After all, that is what will ultimately be actually coded in resulting binary classes.

That could be different if the compiler produced byte-code directly or if minor classes where implemented differently in intermediate java code..

 

Perhaps a new visibility keyword would be the answer -- one that indicated an almost-private property that could only be seen in the current class and its dependents (and that therefore should not have its name changed, for example).

I'm getting the impression that we're dealing with a broader issue here. One which stems from the very concept of minor classes in the context of NetRexx against their actual implementation. Following discussion applies to minor classes in general, dependent or not.

While reviewing the tech doc mentioned previously I found the following quote:

"Specifically, nested classes primarily offer a naming (packaging) convention,
with little effect on scope. In addition, the rules added for member classes
are similar to those that relate a subclass to its superclass; indeed, in some
ways, member classes offer an alternative (though less flexible) inheritance hierarchy.
Seen in this light, inner classes of both types are no more 'inside' their parent
class than a subclass is 'inside' its superclass."

Well, OK. The problem arises when we consider that 'this light' is just a narrow band of the full radio-electric spectrum. For example, turning a bit our wavelength dial we could say.

"Specifically, nested classes (static or not --minor or minor dependent--) are inherited
by subclasses extending the container class.
Seen under this light, inner classes are as 'inside' their containing class as it gets,
subject to the same scope and access rules as any other members (properties or methods)
of the containing class. "

I'll be demonstrating this statement bellow.

Admittedly, what particular features NetRexx offers is up to its specification. NetRexx might offer a 'minor classes' feature which is not related to java's 'nested classes' in any way (or just partially). That would be all good and well.

But then:

- They should not be advertised as a "means of accessing and creating externally visible inner classes" nor as a form of "support access to these classes (and, by implication, allow their definition"

- They should not be implemented by means of a java's feature with different semantics and much broader implications.

Today both of these conditions are not met, leading to situations like the following:

Lets have a class 'ContainerClass' having both a minor class 'RegularMinorClass' and a dependent class 'DependentMinorClass'.

class ContainerClass public
   
    properties public
        _dependentMinorClass = ContainerClass.DependentMinorClass
        _prop = String
       
    method ContainerClass(containerProp=String)
        _prop = containerProp
        _dependentMinorClass = this.DependentMinorClass()
       
    method main(args=String[]) static
        mCT = ContainerClass('_prop at MinorTestClass')
        mCT._dependentMinorClass.dependentMinorGreet()
        RegularMinorClass.regularMinorGreet()

class ContainerClass.RegularMinorClass public

    method RegularMinorClass() public
        nop
       
    method regularMinorGreet() static
        Say 'Hello from RegularMinorClass'
   

class ContainerClass.DependentMinorClass dependent public
   
    method DependentMinorClass()
        nop
       
    method dependentMinorGreet()
        Say 'Hello from DependentMinorClass (parent.prop:' parent._prop')'


OK, NetRexx does not consider minor classes as being 'inside' so they won't be inherited by any classes extending ContainerClass. Lets try to demonstrate this. The following class won't even compile (rightly according to the spec.).

class NrxSubclassedContainerClass extends ContainerClass
   
    method NrxSubclassedContainerClass(containerProp=String)
        super(containerProp)
   
    method main(args=String[]) static
       
        sMCT = NrxSubclassedContainerClass("_prop at SubclassedMinorClassTest")
       
        -- According to NetRexx RegularMinorClass is not inherited. doh!
        --
        --   The property 'RegularMinorClass' cannot be found in class 'NrxSubclassedContainerClass' or a superclass
        --
        -- it doesn't even consider the posibility of an inherited minor
        -- class so bails about an inexistent property
        --
        NrxSubclassedContainerClass.RegularMinorClass.regularMinorGreet()
       
        -- According to NetRexx DependentMinorClass isn't inherited either
        --
        --   The method 'DependentMinorClass()' cannot be found in class 'NrxSubclassedContainerClass' or a superclass
        --
        -- same here: compiler gets confused looking for a method instead
        -- of a constructor for an inherited minor dependent class
        --
        dMC = sMCT.DependentMinorClass()
       
       
        -- curiously this doesn't raise an error...
        dMC.dependentMinorGreet()

Now, here comes our fellow java programer which sees some value in extending our ContainerClass. He'll be using the exact equivalent java code for the above NrxSubclassedContainerClass (save the comments).

class JavaSubclassedContainerClass extends MinorClassTest {
   
    public JavaSubclassedContainerClass(String containerProp) {
        super(containerProp);
    }
   
    public static void main(String[] args) {
       
        JavaSubclassedContainerClass sMCT =
            new JavaSubclassedContainerClass("_prop at JavaSubclassedContainerClass");
       
        // lets check if we inherited RegularMinorClass
        JavaSubclassedContainerClass.RegularMinorClass.regularMinorGreet();
   
        // lets check if we inherited DependentMinorClass
        DependentMinorClass dMC = sMCT.new DependentMinorClass();
        dMC.dependentMinorGreet();
    }
}

He compiles it against our very same NetRexx generated binary ContainerClass and not only succeeds but when he runs it he gets:

Hello from RegularMinorClass
Hello from DependentMinorClass (parent.prop: _prop at JavaSubclassedMinorClassTest)

See? NetRexx does not provide for actual 'inside' inner classes, it actually even forbids minor class inheritance. But its ultimately generating that very same code. Meanwhile, the NetRexx programmer has no means whatsoever how other code in the jvm could exploit this fact.

This was just an aspect of the issue with current minor classes.

Access to private members of the parent class from its dependents is another.

As is the possibility of qualifying a minor class itself as 'public', 'private', 'shared' or nothing at all (same as 'shared'); but not 'inheritable'!
BTW, the spec. does not mention shared (or default access) minor classes at all.

Or the confusion created by the parent/child terminology which tends to relate minor classes to some form of inheritance.

etc. etc. etc..

Sorry for a loooong, dense, post :-)


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

David, thanks for the long post, etc.    The underlying problem here is that I think 'inner classes' were a poor addition to Java (often abused, as you say), but NetRexx needed to support the key parts of the concept to "remain competitive".  I tried to do that while avoiding the 'inner' nesting part, which I found unhelpful.   There's room for improvement, no doubt, but NetRexx is constrained by the need to generate pure Java code ...

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Mike, and ALL

I understand this is probably not the place, nor the time to discus these matters but, well, lets have Nable archive this for future reference :-)

El 05/08/2010 10:18, Mike Cowlishaw escribió:

David, thanks for the long post, etc.    The underlying problem here is that I think 'inner classes' were a poor addition to Java (often abused, as you say),

I concur with both (that being the underlying problem and inner classes being a poor addition)

but NetRexx needed to support the key parts of the concept to "remain competitive".

Well, IMHO supplying a crippled support to a feature which has become broadly used overtime gives NetRexx not much in the camp of competitiveness

I tried to do that while avoiding the 'inner' nesting part, which I found unhelpful.

But the whole point with inner classes is their innerness, not supporting a 'less flexible inheritance mechanism'.

I do not object to the omission of local and anonymous classes which support nothing that couldn't be made with regular non static inner classes but instead rise the astonishing factor of the language to amazing heights but...

It's not java 1.1's time any more. Inner classes support key idioms across the java library itself. Two issues from the top of my mind:

Currently any time you need a given object modified from a different thread, you currently need to provide a reference to it as well as exposing needed properties or provide some accessible setter methods (so the launched Thread or Runnable instance can perform its task). This is forcing the developer to clutter his classes interface with properties and/or behaviours which really do belong to its internal workings.

Currently NetRexx does not recognize minor classes as an inheritable part of a given class. This renders the sub-classing mechanism unusable when you need to extend a java library class (or any other third party class) which implements a key part of its behaviour by means of a private inner class. To be honest, I haven't tried to up-cast 'this' to 'supper'but even if it worked, well, that would be a truly awful construct!

There's room for improvement, no doubt, but NetRexx is constrained by the need to generate pure Java code ...

Well, yes, it undoubtedly does.

What it does not currently is honour its own specification as it generates java bytecode which does not conform. For one, classes on the jvm generated form other languages (java, clojure, jYthon, jRuby, etc) can use our NetRexx classes with different access rules to the ones we're allowed to specify.

One of the main selling points of NetRexx is being able to unleash the full power of the java platform from a better than java language. That goal is not met :-(

Another one is being able to transparently use java classes an vice versa. That relation is today at least not symetrical :-(


---

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

All good points, but I really do not think back in 1999 anyone could have made a better prediction on the usage of Inner Classes.  Mine was closer than most, I think.   But almost everyone (except the designer) disliked them, and their syntax in particular.

 

Just a couple of followups ...

What it does not currently is honour its own specification as it generates java bytecode which does not conform. For one, classes on the jvm generated form other languages (java, clojure, jYthon, jRuby, etc) can use our NetRexx classes with different access rules to the ones we're allowed to specify. 

 

Hang on .. the bytecodes are generated by javac, not by NetRexx, so they certainly conform.  (One of the reasons I held back from generating bytecodes directly was that many debugging tools, etc., only worked with bytecode sequences that were 'expected' -- i.e., as generated by javac.  Better sequences could -- and did -- cause problems with third-party tools.) 

 

On the access rules -- I would argue that people coding in NetRexx will be writing safer and more robust code because of those rules -- and beacuse of many other rules and checks that NetRexx does, too (consider the various "strict" compile options, for example). 

One of the main selling points of NetRexx is being able to unleash the full power of the java platform from a better than java language. That goal is not met :-( 

 

This may be a valid point -- I forget the details -- but if that power results in unmaintainable code because higher-level classes can no longer assume the work 'private' means 'private', then it is a loss.   As I mentioned in an earlier post .. if some other class (anywhere -- subclass or whatever) can even 'see', let alone 'alter' something that is identified as Private, then that something is not private.   Call it "pseudoprivate", or "obfuscated", perhaps, but it is not private.

 
Another one is being able to transparently use java classes an vice versa. That relation is today at least not symetrical :-( 

 

I think that's just another way of saying the same thing.  :-) 
 

In general -- over most flaws in the design of Java one has to grit ones teeth and accept.   This flaw was one where I thought it was a step too far.  You are all perfectly justified in saying, with hindsight, that I was wrong (I really thought Inner Classes would die out once people saw how ugly they are) -- so do please go ahead and fix in NetRexx 3!   [But do please use a different keyword than "private" :-).]

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Mike,

I'm of course not criticising design decisions taken ten years ago, but proposing enhancements for years to come :-)

I do dislike inner classes as you do. Sun did a great mess with that and even kludgey hacked their implementation into the jvm.
Unfortunately they're here to stay.

As for access to private members from minor classes, your objection just stands as long as you consider minor classes as non-member (or not inside) which is precisely what I propose to revise when the time comes.

Surely you wouldn't argue granting private properties access from member methods :-)

I hope there's still someone around if the time for a NetRexx 3.0 finally comes upon us!

El 17/08/2010 15:42, Mike Cowlishaw escribió:

All good points, but I really do not think back in 1999 anyone could have made a better prediction on the usage of Inner Classes.  Mine was closer than most, I think.   But almost everyone (except the designer) disliked them, and their syntax in particular.

 

Just a couple of followups ...

What it does not currently is honour its own specification as it generates java bytecode which does not conform. For one, classes on the jvm generated form other languages (java, clojure, jYthon, jRuby, etc) can use our NetRexx classes with different access rules to the ones we're allowed to specify. 

 

Hang on .. the bytecodes are generated by javac, not by NetRexx, so they certainly conform.  (One of the reasons I held back from generating bytecodes directly was that many debugging tools, etc., only worked with bytecode sequences that were 'expected' -- i.e., as generated by javac.  Better sequences could -- and did -- cause problems with third-party tools.) 

 

On the access rules -- I would argue that people coding in NetRexx will be writing safer and more robust code because of those rules -- and beacuse of many other rules and checks that NetRexx does, too (consider the various "strict" compile options, for example). 

One of the main selling points of NetRexx is being able to unleash the full power of the java platform from a better than java language. That goal is not met :-( 

 

This may be a valid point -- I forget the details -- but if that power results in unmaintainable code because higher-level classes can no longer assume the work 'private' means 'private', then it is a loss.   As I mentioned in an earlier post .. if some other class (anywhere -- subclass or whatever) can even 'see', let alone 'alter' something that is identified as Private, then that something is not private.   Call it "pseudoprivate", or "obfuscated", perhaps, but it is not private.

 
Another one is being able to transparently use java classes an vice versa. That relation is today at least not symetrical :-( 

 

I think that's just another way of saying the same thing.  :-) 
 

In general -- over most flaws in the design of Java one has to grit ones teeth and accept.   This flaw was one where I thought it was a step too far.  You are all perfectly justified in saying, with hindsight, that I was wrong (I really thought Inner Classes would die out once people saw how ugly they are) -- so do please go ahead and fix in NetRexx 3!   [But do please use a different keyword than "private" :-).]

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

 >  I hope there's still someone around if the time for a NetRexx 3.0 finally comes upon us!
 

That would seem to be the most important issue at the moment.

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Agreed. Open sourcin process is lingering beyond any reasonable time span.

Meanwhile the alternative jvm languages arena is getting pretty crowded as shown at

http://en.m.wikipedia.org/wiki/List_of_JVM_languages

-
Saludos / Kind regards,
David Requena

-----Original Message-----
From: "Mike Cowlishaw" <[hidden email]>
Sender: [hidden email]
Date: Tue, 17 Aug 2010 17:13:38
To: 'IBM Netrexx'<[hidden email]>
Reply-To: IBM Netrexx <[hidden email]>
Subject: RE: NetRexx Minor classes (WAS: Re:
        FW:[Ibm-netrexx][Enhancementproposal]:Dependent classes and
        access to ...)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Tom Maynard]

  On 8/17/2010 12:15 PM, David Requena wrote:
> Meanwhile the alternative jvm languages arena is getting pretty crowded as shown at
>
> http://en.m.wikipedia.org/wiki/List_of_JVM_languages
>
I personally keep a close watch on that (or similar) lists of JVM
languages.  I'm surprised at the omission of Beanshell -- perhaps
because of the lack of recent activity?


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hello David,
    first thanks for publishing that link :-)
    second, I looked at it, but did NOT find NetRexx there :-(
    It's a pity!

    Did I look at come wrong place, or what ?

Third:

Rene, I personally think it *is the time* that you do publish a
*tentative* date of NetRexx going open
source and the still pending decision, too, when you are allowed to do so...
Tom.
==============================================================================
Am 17.08.2010 19:15, schrieb David Requena:

> Agreed. Open sourcin process is lingering beyond any reasonable time span.
>
> Meanwhile the alternative jvm languages arena is getting pretty crowded as shown at
>
> http://en.m.wikipedia.org/wiki/List_of_JVM_languages
>
> -
> Saludos / Kind regards,
> David Requena
>
> -----Original Message-----
> From: "Mike Cowlishaw"<[hidden email]>
> Sender: [hidden email]
> Date: Tue, 17 Aug 2010 17:13:38
> To: 'IBM Netrexx'<[hidden email]>
> Reply-To: IBM Netrexx<[hidden email]>
> Subject: RE: NetRexx Minor classes (WAS: Re:
> FW:[Ibm-netrexx][Enhancementproposal]:Dependent classes and
> access to ...)
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hello Tom Maynard,
    I must admit that I am a member of [nbdev], the netbeans development
group.
    Currently just for info what is going there on....

May I report that the *is* activity there ! (more as on ibm-netrexx, as
far as i can see, ecept today, of course).

Another Tom (Thomas Schneider)
=====================================================================================
Am 17.08.2010 20:18, schrieb Tom Maynard:

>  On 8/17/2010 12:15 PM, David Requena wrote:
>> Meanwhile the alternative jvm languages arena is getting pretty
>> crowded as shown at
>>
>> http://en.m.wikipedia.org/wiki/List_of_JVM_languages
>>
> I personally keep a close watch on that (or similar) lists of JVM
> languages.  I'm surprised at the omission of Beanshell -- perhaps
> because of the lack of recent activity?
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 18 August 2010 07:13, Thomas Schneider <[hidden email]> wrote:

 Hello David,
  first thanks for publishing that link :-)
  second, I looked at it, but did NOT find NetRexx there :-(
  It's a pity!

  Did I look at come wrong place, or what ?

Yes.  It's there, large as life.  Here's the follow-on link to the NetRexx page referenced by that page: http://en.m.wikipedia.org/wiki/IBM_NetRexx

_______________________________________________
Ibm-netrexx mailing list
[hidden email]