FW: [Ibm-netrexx] [Enhancement proposal]: Dependent classes andaccess to parent object's members

[Mike Cowlishaw]

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Mike

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mike Cowlishaw
Sent: 20 July 2010 17:50
To: 'IBM Netrexx'
Subject: RE: [Ibm-netrexx] [Enhancement proposal]: Dependent classes andaccess to parent object's members

Please, post back your views and comments. Mike, you there? At some point you'll need to land, at least for a refuelling ;-)
 

Yes, I'm here for a few days (just back from 2 weeks vacation).  :-) 

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private -- so changing/removing them could break subclasses.   Surely not good.  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Peter Montague]

Dear Mr. Cowlishaw--

Can you tell me how to unsubscribe from the netrexx listserv?

Thanks very much.

--Peter Montague
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

I  would lke to follow this trail. . . . .

bobh

On Tue, Jul 20, 2010 at 7:04 PM, Peter Montague <[hidden email]> wrote:

Dear Mr. Cowlishaw--

Can you tell me how to unsubscribe from the netrexx listserv?

Thanks very much.

--Peter Montague
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Bruce Skelly]

The help file says to send a message [hidden email].

In the body of the message put 'unsubscribe'.

If you have set a password, then 'unsubscribe password'.

As always you don't type the quotes.

If you need more information send a help message to the address above.

Bruce

On Jul 20, 2010, at 8:32 PM, Robert Hamilton wrote:

I  would lke to follow this trail. . . . .

bobh

On Tue, Jul 20, 2010 at 7:04 PM, Peter Montague <[hidden email]> wrote:

Dear Mr. Cowlishaw--

Can you tell me how to unsubscribe from the netrexx listserv?

Thanks very much.

--Peter Montague
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

David,

maybe a good example can do the job. I tend to only use them for GUI stuff - which I do in Java, and then also I have visibility problems - unless you make them - what was it - static? immutable? (if I remember well - which I apparently do not). Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

best regards,

René Jansen.

On 21 jul 2010, at 12:26, David Requena wrote:

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 21/07/2010 13:27, René Jansen escribió:

maybe a good example can do the job.

OK, see bellow

I tend to only use them for GUI stuff - which I do in Java,

part of what I'm trying to illustrate is that currently you really cannot do it properly in NetRexx. Admittedly there're many good tools to do this stuff in java :-)

and then also I have visibility problems - unless you make them - what was it - static? immutable?

Well, static would give you an equivalent of a regular Minor, *non dependent* class in NetRexx. This won't allow access to any instance members private or not, just static members.
This is a different beast to a dependent minor class (inner non-static , non-anonymous class in java) which is what we talk about here.

(if I remember well - which I apparently do not).

I don't seem to remember about immutable either ;-)

Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

OK, here we go: David's silly click counter :-)

I'll be using a little app which shows a counter and a button. Each time the button is clicked the counter increments. In order to keep things simple, I'll be elaborating on just one of the issues I mentioned earlier.

Latter I'll demonstrate how this differs from how things work in the jvm itself

First a screenshot:



Now for the code. Focus here is in 'properties private' in red in the source bellow

import javax.swing.

class FlawedDependentSample extends JFrame
   
    /* these should be private. No external code should update them.
       Compilation breaks under current reference implementation so
       we use the next least restrictive qualifier (shared) */
      
    properties private
        clickCount = 0  -- both updated from button eventlistener
        counter = JLabel
           
    method main(args=String[]) static
        FlawedDependentSample()
       
    method FlawedDependentSample()
        SwingUtilities.invokeLater(this.UIBuilder())

      
class FlawedDependentSample.UIBuilder dependent implements Runnable
   
    /* We run this on the AWTThread as mandated by the swing specification */

    method run()
        parent.setTitle("..:: Click counter ::..")
        parent.setSize(200, 100)
        parent.setLayout(GridLayout(0, 1))
        parent.counter = JLabel("Clicks so far: 0")  -- also breaks..
        parent.add(parent.counter)   
        button = JButton("Click Here")
        button.addActionListener(parent.myActionListener())
        parent.add(button)   
        parent.setVisible(1)

       
class FlawedDependentSample.myActionListener dependent implements ActionListener
   
    /* this will break when clickCount and counter are private */
   
    method actionPerformed(e=ActionEvent)
        parent.clickCount = parent.clickCount + 1
        parent.counter.setText("Clicks so far:" parent.clickCount)

This fails with:

Error: The property 'FlawedDependentSample.counter' was found, but is not accessible from class 'FlawedDependentSample.UIBuilder'
Error: The property 'FlawedDependentSample.counter' was found, but is not accessible from class 'FlawedDependentSample.UIBuilder'
Error: The property 'FlawedDependentSample.clickCount' was found, but is not accessible from class 'FlawedDependentSample.myActionListener'
Error: The property 'FlawedDependentSample.counter' was found, but is not accessible from class 'FlawedDependentSample.myActionListener'
 
Yeah, OK, cannot access private members from here.. So we choose the next least restrictive qualifier for our 2 properties: shared.

    properties shared
        clickCount = 0  -- both updated from button eventlistener
        counter = JLabel


Now everything seems to work. But... wait!!

Suddenly any class whose code is placed at our same package (default one in this instance) can increment our counter or our our display without the user ever clicking on the button!
What is even worse, that code could modify one property an not the other, putting our whole app in an inconsistent state.

Qualifying them as inheritable would just allow more outer code to access them.

Of course this is what 'information hiding' is all about: Internal state of a class must remain private.

Now onto HOW NETREXX's IMPLEMENTATION DIFFERS FROM THE ACTUAL JVM's IMPLEMENTATION

OK, lets assume the translator had let us compile the first version. Here is the relevant intermediate java code generated:

public class FlawedDependentSample extends javax.swing.JFrame{
 private static final java.lang.String $0="FlawedDependentSample.nrx";
  private static final netrexx.lang.Rexx $01=new netrexx.lang.Rexx(1);
 
 /* these should be private. No external code should update them.
        Compilation breaks under current reference implementation so
        we use the next least restrictive qualifier (shared) */
 
 /* properties shared */
 netrexx.lang.Rexx clickCount=new netrexx.lang.Rexx((byte)0); // both updated from button eventlistener
 javax.swing.JLabel counter;

 ... code follows ...
 

We can see no qualifier got prefixed to our variables so they have package visibility (same thing as shared in NetRexx). Lets 'privatify' them:

 /* properties shared */
  private netrexx.lang.Rexx clickCount=new netrexx.lang.Rexx((byte)0); // both updated from button eventlistener
  private javax.swing.JLabel counter;

 ... code follows ...

 That, of course, works a treat. Our state remains inaccessible from outer code while we can still modify it from a different thread but from WITHIN our own class code (please, see bellow the full generated java code to apreciate how dependent classes become effectively *inner* or *local* classes).

>From :

    "Since these can be exposed in published specifications, languages that are to take full advantage
    of the Java environment must support access to these classes (and, by implication, allow their definition)."

Well, by implementing 'these classes' in a similar but arbitrarily different way NetRexx has put itself in a position of inability to 'take full advantage of the Java environment'

Full generated java code follows

/* Generated from 'FlawedDependentSample.nrx' 21 Jul 2010 13:28:27 [v2.05] */
/* Options: Comments Compact Crossref Decimal Format Java Logo Replace Trace2 Verbose3 */




public class FlawedDependentSample extends javax.swing.JFrame{
 private static final java.lang.String $0="FlawedDependentSample.nrx";
  private static final netrexx.lang.Rexx $01=new netrexx.lang.Rexx(1);
 
 /* these should be private. No external code should update them.
        Compilation breaks under current reference implementation so
        we use the next least restrictive qualifier (shared) */
 
 /* properties shared */
 netrexx.lang.Rexx clickCount=new netrexx.lang.Rexx((byte)0); // both updated from button eventlistener
 javax.swing.JLabel counter;

 
 
 public static void main(java.lang.String args[]){
  new FlawedDependentSample();
  return;}

 
 public FlawedDependentSample(){super();
  javax.swing.SwingUtilities.invokeLater((java.lang.Runnable)(this.new UIBuilder()));
  return;}

 
 class UIBuilder implements java.lang.Runnable{
  private final transient java.lang.String $0="FlawedDependentSample.nrx";

 
 /* We run this on the AWTThread as mandated by the swing specification */
 
 
  public void run(){
   javax.swing.JButton button;
   FlawedDependentSample.this.setTitle("..:: Click counter ::..");
   FlawedDependentSample.this.setSize(200,100);
   FlawedDependentSample.this.setLayout((java.awt.LayoutManager)(new java.awt.GridLayout(0,1)));
   FlawedDependentSample.this.counter=new javax.swing.JLabel("Clicks so far: 0"); // also breaks..
   FlawedDependentSample.this.add((java.awt.Component)FlawedDependentSample.this.counter);
   button=new javax.swing.JButton("Click Here");
   button.addActionListener((java.awt.event.ActionListener)(FlawedDependentSample.this.new myActionListener()));
   FlawedDependentSample.this.add((java.awt.Component)button);
   FlawedDependentSample.this.setVisible(true);
   return;}
 
  public UIBuilder(){return;}
  }

 
 
 class myActionListener implements java.awt.event.ActionListener{
  private final transient java.lang.String $0="FlawedDependentSample.nrx";

 
 /* this will break when clickCount and counter are private */
 
 
  public void actionPerformed(java.awt.event.ActionEvent e){
   FlawedDependentSample.this.clickCount=FlawedDependentSample.this.clickCount.OpAdd(null,$01);
   FlawedDependentSample.this.counter.setText(netrexx.lang.Rexx.toString(netrexx.lang.Rexx.toRexx("Clicks so  far:").OpCcblank(null,FlawedDependentSample.this.clickCount)));
   return;}
 
  public myActionListener(){return;}
 }}


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

David wrote: 

 

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.  (And raises issues of whether subclasses of a dependent calls can 'see' them, and so on.)

 

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).

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Rene,

I'm addressing this to you since, as far as I can tell, you are the president of RexxLA, and that organization apparently will take charge of NetRexx when it is made open source.  While we wait for Godot a substantive discussion about NetRexx changes seems to be starting.  I have nothing to contribute to that, though I'm listening with interest.

I wonder if you could outline RexxLA's approach to the change process?  Logically, I would expect to find the answer at RexxLA's website, but I have found that site strangely unenlightening.  [I joined RexxLA in a fit of excitement at the news of NetRexx's open sourcing, but now it is not clear to me what the benefits of membership are.]

George

On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:

David,

maybe a good example can do the job. I tend to only use them for GUI stuff - which I do in Java, and then also I have visibility problems - unless you make them - what was it - static? immutable? (if I remember well - which I apparently do not). Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

best regards,

René Jansen.

On 21 jul 2010, at 12:26, David Requena wrote:

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 

---
Saludos / Kind regards.
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

Has there been any further word on NetRexx open source deal. I have a project on top dead center because the folks don't won't to deal w/ big blue. . . . I don't even want to know why.

thnx

bobh

On Thu, Jul 22, 2010 at 1:34 PM, George Hovey <[hidden email]> wrote:

Rene,

I'm addressing this to you since, as far as I can tell, you are the president of RexxLA, and that organization apparently will take charge of NetRexx when it is made open source.  While we wait for Godot a substantive discussion about NetRexx changes seems to be starting.  I have nothing to contribute to that, though I'm listening with interest.

I wonder if you could outline RexxLA's approach to the change process?  Logically, I would expect to find the answer at RexxLA's website, but I have found that site strangely unenlightening.  [I joined RexxLA in a fit of excitement at the news of NetRexx's open sourcing, but now it is not clear to me what the benefits of membership are.]

George

On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:

David,

maybe a good example can do the job. I tend to only use them for GUI stuff - which I do in Java, and then also I have visibility problems - unless you make them - what was it - static? immutable? (if I remember well - which I apparently do not). Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

best regards,

René Jansen.

On 21 jul 2010, at 12:26, David Requena wrote:

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 

---
Saludos / Kind regards.
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Kermit Kiser]

I can't follow this "dependent" vs "private" discussion since it has not impacted me personally yet, but I have two cents to add while we are discussing changes in this area. It seems to me that the main benefit of minor classes is that you can define them at the point they are used (in Java code that is). Putting them at the end of the parent class (as in NetRexx code) defeats most of the purpose for me. I would like to have an "End-Class" type of statement that allows dependent classes to be defined "inline". That way you could see what a "listener" does when looking at the code that sets it, like you can in Java. Anyone see problems with that?

-- Kermit


On 7/22/2010 12:57 AM, Mike Cowlishaw wrote:

David wrote: 

 

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.  (And raises issues of whether subclasses of a dependent calls can 'see' them, and so on.)

 

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).

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

Bob, the terms of use are pretty liberal.  Curious how would having it open source have helped you?

 

  from \netrexx\lang\LICENSE.TXT :

 

         IBM License Agreement for IBM Employee-Written Software

    -----------------------------------------------------------------

 

 

    IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.

 

    International Business Machines Corporation grants you a license

    to use the Program only in the country where you acquired it. The

    Program is copyrighted and licensed (not sold). We do not

    transfer title to the Program to you. You obtain no rights other

    than those granted you under this license.

 

    Under this license, you may:

 

    1. use the Program on one or more machines at a time;

    2. make copies of the Program for use or backup purposes within

       your Enterprise;

    3. modify the Program and merge it into another program; and

    4. make copies of the original file you downloaded and distribute

       it, provided that you transfer a copy of this license to the

       other party. The other party agrees to these terms by its

       first use of the Program.

 

    You must reproduce the copyright notice and any other legend of

    ownership on each copy or partial copy, of the Program.

 

    You may NOT:

 

    1. sublicense, rent, lease, or assign the Program; and

    2. reverse assemble, reverse compile, or otherwise translate the

       Program.

 

We do not warrant that the Program is free from claims by a third

 party of copyright, patent, trademark, trade secret, or any other

 intellectual property infringement.

 

 Under no circumstances are we liable for any of the following:

 

 1. third-party claims against you for losses or damages;

 2. loss of, or damage to, your records or data; or

 3. economic consequential damages (including lost profits or

    savings) or incidental damages, even if we are informed of

    their possibility.

 

 Some jurisdictions do not allow these limitations or exclusions,

 so they may not apply to you.

 

 We do not warrant uninterrupted or error free operation of the

 Program. We have no obligation to provide service, defect

 correction, or any maintenance for the Program. We have no

 obligation to supply any Program updates or enhancements to you

 even if such are or later become available.

 

 

 IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.

 

 THERE ARE NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING THE

 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A

 PARTICULAR PURPOSE.

 

 Some jurisdictions do not allow the exclusion of implied

 warranties, so the above exclusion may not apply to you.

 

 You may terminate this license at any time. We may terminate this

 license if you fail to comply with any of its terms. In either

 event, you must destroy all your copies of the Program.

 

 You are responsible for the payment of any taxes resulting from

 this license.

 

 You may not sell, transfer, assign, or subcontract any of your

 rights or obligations under this license. Any attempt to do so is

 void.

 

 Neither of us may bring a legal action more than two years after

 the cause of action arose.

 

 If you acquired the Program in the United States, this license is

 governed by the laws of the State of New York. If you acquired

 the Program in Canada, this license is governed by the laws of

 the Province of Ontario. Otherwise, this license is governed by

 the laws of the country in which you acquired the Program.

 

3/92

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Hamilton
Sent: Thursday, July 22, 2010 3:07 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] [Enhancement proposal]: Dependent classes andaccessto parent object's members

 

Has there been any further word on NetRexx open source deal. I have a project on top dead center because the folks don't won't to deal w/ big blue. . . . I don't even want to know why.

thnx

bobh

On Thu, Jul 22, 2010 at 1:34 PM, George Hovey <[hidden email]> wrote:

Rene,

I'm addressing this to you since, as far as I can tell, you are the president of RexxLA, and that organization apparently will take charge of NetRexx when it is made open source.  While we wait for Godot a substantive discussion about NetRexx changes seems to be starting.  I have nothing to contribute to that, though I'm listening with interest.

I wonder if you could outline RexxLA's approach to the change process?  Logically, I would expect to find the answer at RexxLA's website, but I have found that site strangely unenlightening.  [I joined RexxLA in a fit of excitement at the news of NetRexx's open sourcing, but now it is not clear to me what the benefits of membership are.]

George

On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:

David,

 

maybe a good example can do the job. I tend to only use them for GUI stuff - which I do in Java, and then also I have visibility problems - unless you make them - what was it - static? immutable? (if I remember well - which I apparently do not). Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

 

best regards,

 

René Jansen.

 

On 21 jul 2010, at 12:26, David Requena wrote:

 

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 

---

Saludos / Kind regards.

David Requena

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

It's two local public universities and two private colleges -- Devry and ITT. One of the Universities had taught MVS REXX  on a machine in Poughkeepsie, evidently at Marist but they think one machine was actually at IBM.  I took them the license agreement.  I'm puzzled by this, myself.  One of the public schools is toying with Mainframe instructions.  Some big corps here in Dallas run z/os etc. and they are encouraging the public colleges to offer more MF courses. 

I tried to get jEDIT to work with NetRexx but it was too erratic and I could never get it to work consistently.  ooREXX 4.0 has a rexx try that I demonstrated to the Provost at one college. They were interested but never followed through and this fall's schedule has no such classes listed. 

They wrote the ATM record problem in C++ and I demoed the  code in NetRexx on my laptop. This was the problem with the numeric values scattered thru an unformatted record.  They were impressed but I could not nudge them into offering a REXX or NetRexx class.

 bobh  

On Fri, Jul 23, 2010 at 11:23 AM, Measel, Mike <[hidden email]> wrote:

Bob, the terms of use are pretty liberal.  Curious how would having it open source have helped you?

 

  from \netrexx\lang\LICENSE.TXT :

 

         IBM License Agreement for IBM Employee-Written Software

    -----------------------------------------------------------------

 

 

    IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.

 

    International Business Machines Corporation grants you a license

    to use the Program only in the country where you acquired it. The

    Program is copyrighted and licensed (not sold). We do not

    transfer title to the Program to you. You obtain no rights other

    than those granted you under this license.

 

    Under this license, you may:

 

    1. use the Program on one or more machines at a time;

    2. make copies of the Program for use or backup purposes within

       your Enterprise;

    3. modify the Program and merge it into another program; and

    4. make copies of the original file you downloaded and distribute

       it, provided that you transfer a copy of this license to the

       other party. The other party agrees to these terms by its

       first use of the Program.

 

    You must reproduce the copyright notice and any other legend of

    ownership on each copy or partial copy, of the Program.

 

    You may NOT:

 

    1. sublicense, rent, lease, or assign the Program; and

    2. reverse assemble, reverse compile, or otherwise translate the

       Program.

 

We do not warrant that the Program is free from claims by a third

 party of copyright, patent, trademark, trade secret, or any other

 intellectual property infringement.

 

 Under no circumstances are we liable for any of the following:

 

 1. third-party claims against you for losses or damages;

 2. loss of, or damage to, your records or data; or

 3. economic consequential damages (including lost profits or

    savings) or incidental damages, even if we are informed of

    their possibility.

 

 Some jurisdictions do not allow these limitations or exclusions,

 so they may not apply to you.

 

 We do not warrant uninterrupted or error free operation of the

 Program. We have no obligation to provide service, defect

 correction, or any maintenance for the Program. We have no

 obligation to supply any Program updates or enhancements to you

 even if such are or later become available.

 

 

 IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.

 

 THERE ARE NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING THE

 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A

 PARTICULAR PURPOSE.

 

 Some jurisdictions do not allow the exclusion of implied

 warranties, so the above exclusion may not apply to you.

 

 You may terminate this license at any time. We may terminate this

 license if you fail to comply with any of its terms. In either

 event, you must destroy all your copies of the Program.

 

 You are responsible for the payment of any taxes resulting from

 this license.

 

 You may not sell, transfer, assign, or subcontract any of your

 rights or obligations under this license. Any attempt to do so is

 void.

 

 Neither of us may bring a legal action more than two years after

 the cause of action arose.

 

 If you acquired the Program in the United States, this license is

 governed by the laws of the State of New York. If you acquired

 the Program in Canada, this license is governed by the laws of

 the Province of Ontario. Otherwise, this license is governed by

 the laws of the country in which you acquired the Program.

 

3/92

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Hamilton
Sent: Thursday, July 22, 2010 3:07 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] [Enhancement proposal]: Dependent classes andaccessto parent object's members

 

Has there been any further word on NetRexx open source deal. I have a project on top dead center because the folks don't won't to deal w/ big blue. . . . I don't even want to know why.

thnx

bobh

On Thu, Jul 22, 2010 at 1:34 PM, George Hovey <[hidden email]> wrote:

Rene,

I'm addressing this to you since, as far as I can tell, you are the president of RexxLA, and that organization apparently will take charge of NetRexx when it is made open source.  While we wait for Godot a substantive discussion about NetRexx changes seems to be starting.  I have nothing to contribute to that, though I'm listening with interest.

I wonder if you could outline RexxLA's approach to the change process?  Logically, I would expect to find the answer at RexxLA's website, but I have found that site strangely unenlightening.  [I joined RexxLA in a fit of excitement at the news of NetRexx's open sourcing, but now it is not clear to me what the benefits of membership are.]

George

On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:

David,

 

maybe a good example can do the job. I tend to only use them for GUI stuff - which I do in Java, and then also I have visibility problems - unless you make them - what was it - static? immutable? (if I remember well - which I apparently do not). Maybe you can include a sample of something that breaks using the current compiler, but will be suffiently persuasive for people to start wondering.

 

best regards,

 

René Jansen.

 

On 21 jul 2010, at 12:26, David Requena wrote:

 

El 20/07/2010 21:03, Mike Cowlishaw escribió:

SHORT SUMMARY
=============

Instances of dependent classes don't have privileged access to parent objects' members but they should. In particular, private members are inaccessible to them. This issue invalidates many common use patterns for member classes. This access restriction is not documented anywhere but is in fact enforced by the reference implementation's compiler.

This memo proposes modification of the reference implementation so it grants access to parent objects private members from dependent classes' instances.

Hmmm ... but then the private variables would no longer be private

Why so? They wouldn't lose their 'privateness' any more than by being accessible by member methods of the class (which of course they are).

-- so changing/removing them could break subclasses.

Again, why so? At which point did I propose to make them available to subclasses? For this we already have inheritable

Surely not good.

I would agree if that had anything to do with what I'm proposing..

  If they are visible to *any* other class they should be marked as such (i.e., not PRIVATE)?

private properties must not be accessible from anywhere outside their defining class, agreed. But as a mater of fact member classes ('dependent classes' in NetRexx parlance) are just that: members of the defining class. You even implemented them like such!

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.

Returning to the analogy of member methods. If you were to remove a private property of a given class, of course you would need to update any methods which accessed it, otherwise the program containing it wouldn't compile. At no point in time subclasses would be affected in any way.
Similarly you would need to update any dependent classes (which by requirement must be present in the same source file --'program' in NetRexx parlance). No subclass is impacted. Not even any other class which happens to use ours is impacted.

Looking at it from another angle: a public dependent class is part of the interface of the class from which it depends. A private dependent class is part of the inner machinery of no concern for any code outside the parent class. Of course both variants must be in sync with the parent class; a requirement which is enforced by the fact that both class definitions must reside at the same compilation unit. (again, just like member methods)

PS .. is not the 'inheritable' visibility just what you are asking for?

 

Absolutely not!!
That would be worse than using shared. Exposing internal state of the depended class not only to classes at the same package but also to subclasses in any package.

At this point I'm not sure whether I made a really poor job explaining myself or you didn't get to read my previous note past the short summary section...
Could you please point out for me how inheritable would alleviate in any way any of the issues described under 'derived issues'?

Inner classes on the jvm have privileged access to outer class members. NetRexx, while trying to support this very feature of the jvm, chose to change this policy; invalidating along the way most of the uses inner classes were designed for in the first place.

This boils down to: in order to hide internal estate to code which is in fact inside the class, we are forced to expose internal state to code which is outside the class. A very awkward way of adhering to the information hiding OO principle IMHO...
 


 

---

Saludos / Kind regards.

David Requena

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Hi George,

I think this is more appropriate for the RexxLA list. However, there
is only good news - except for the speed of the process. Some major
steps have been made lately and I am seeing the day approach that I
can make an announcement. At that moment, structure, goals and
milestones also will be announced.

best regards,

René Jansen.

On Thu, Jul 22, 2010 at 8:34 PM, George Hovey <[hidden email]> wrote:

> Rene,
>
> I'm addressing this to you since, as far as I can tell, you are the
> president of RexxLA, and that organization apparently will take charge of
> NetRexx when it is made open source.  While we wait for Godot a substantive
> discussion about NetRexx changes seems to be starting.  I have nothing to
> contribute to that, though I'm listening with interest.
>
> I wonder if you could outline RexxLA's approach to the change process?
> Logically, I would expect to find the answer at RexxLA's website, but I have
> found that site strangely unenlightening.  [I joined RexxLA in a fit of
> excitement at the news of NetRexx's open sourcing, but now it is not clear
> to me what the benefits of membership are.]
>
> George
>
> On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:
>>
>> David,
>> maybe a good example can do the job. I tend to only use them for GUI stuff
>> - which I do in Java, and then also I have visibility problems - unless you
>> make them - what was it - static? immutable? (if I remember well - which I
>> apparently do not). Maybe you can include a sample of something that breaks
>> using the current compiler, but will be suffiently persuasive for people to
>> start wondering.
>> best regards,
>> René Jansen.
>> On 21 jul 2010, at 12:26, David Requena wrote:
>>
>> El 20/07/2010 21:03, Mike Cowlishaw escribió:
>>
>> SHORT SUMMARY
>> =============
>>
>> Instances of dependent classes don't have privileged access to parent
>> objects' members but they should. In particular, private members are
>> inaccessible to them. This issue invalidates many common use patterns for
>> member classes. This access restriction is not documented anywhere but is in
>> fact enforced by the reference implementation's compiler.
>>
>> This memo proposes modification of the reference implementation so it
>> grants access to parent objects private members from dependent classes'
>> instances.
>>
>> Hmmm ... but then the private variables would no longer be private
>>
>> Why so? They wouldn't lose their 'privateness' any more than by being
>> accessible by member methods of the class (which of course they are).
>>
>> -- so changing/removing them could break subclasses.
>>
>> Again, why so? At which point did I propose to make them available to
>> subclasses? For this we already have inheritable
>>
>> Surely not good.
>>
>> I would agree if that had anything to do with what I'm proposing..
>>
>>   If they are visible to *any* other class they should be marked as such
>> (i.e., not PRIVATE)?
>>
>> private properties must not be accessible from anywhere outside their
>> defining class, agreed. But as a mater of fact member classes ('dependent
>> classes' in NetRexx parlance) are just that: members of the defining class.
>> You even implemented them like such!
>>
>> 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.
>>
>> Returning to the analogy of member methods. If you were to remove a
>> private property of a given class, of course you would need to update any
>> methods which accessed it, otherwise the program containing it wouldn't
>> compile. At no point in time subclasses would be affected in any way.
>> Similarly you would need to update any dependent classes (which by
>> requirement must be present in the same source file --'program' in NetRexx
>> parlance). No subclass is impacted. Not even any other class which happens
>> to use ours is impacted.
>>
>> Looking at it from another angle: a public dependent class is part of the
>> interface of the class from which it depends. A private dependent class is
>> part of the inner machinery of no concern for any code outside the parent
>> class. Of course both variants must be in sync with the parent class; a
>> requirement which is enforced by the fact that both class definitions must
>> reside at the same compilation unit. (again, just like member methods)
>>
>> PS .. is not the 'inheritable' visibility just what you are asking for?
>>
>>
>> Absolutely not!!
>> That would be worse than using shared. Exposing internal state of the
>> depended class not only to classes at the same package but also to
>> subclasses in any package.
>>
>> At this point I'm not sure whether I made a really poor job explaining
>> myself or you didn't get to read my previous note past the short summary
>> section...
>> Could you please point out for me how inheritable would alleviate in any
>> way any of the issues described under 'derived issues'?
>>
>> Inner classes on the jvm have privileged access to outer class members.
>> NetRexx, while trying to support this very feature of the jvm, chose to
>> change this policy; invalidating along the way most of the uses inner
>> classes were designed for in the first place.
>>
>> This boils down to: in order to hide internal estate to code which is in
>> fact inside the class, we are forced to expose internal state to code which
>> is outside the class. A very awkward way of adhering to the information
>> hiding OO principle IMHO...
>>
>>
>>
>>
>>
>> ---
>> Saludos / Kind regards.
>> David Requena
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

Good News;

HOORAY!!!!!

bobh

On Sat, Jul 24, 2010 at 6:20 AM, René Jansen <[hidden email]> wrote:

Hi George,

I think this is more appropriate for the RexxLA list. However, there
is only good news - except for the speed of the process. Some major
steps have been made lately and I am seeing the day approach that I
can make an announcement. At that moment, structure, goals and
milestones also will be announced.

best regards,

René Jansen.

On Thu, Jul 22, 2010 at 8:34 PM, George Hovey <[hidden email]> wrote:
> Rene,
>
> I'm addressing this to you since, as far as I can tell, you are the
> president of RexxLA, and that organization apparently will take charge of
> NetRexx when it is made open source.  While we wait for Godot a substantive
> discussion about NetRexx changes seems to be starting.  I have nothing to
> contribute to that, though I'm listening with interest.
>
> I wonder if you could outline RexxLA's approach to the change process?
> Logically, I would expect to find the answer at RexxLA's website, but I have
> found that site strangely unenlightening.  [I joined RexxLA in a fit of
> excitement at the news of NetRexx's open sourcing, but now it is not clear
> to me what the benefits of membership are.]
>
> George
>
> On Wed, Jul 21, 2010 at 7:27 AM, René Jansen <[hidden email]> wrote:
>>
>> David,
>> maybe a good example can do the job. I tend to only use them for GUI stuff
>> - which I do in Java, and then also I have visibility problems - unless you
>> make them - what was it - static? immutable? (if I remember well - which I
>> apparently do not). Maybe you can include a sample of something that breaks
>> using the current compiler, but will be suffiently persuasive for people to
>> start wondering.
>> best regards,
>> René Jansen.
>> On 21 jul 2010, at 12:26, David Requena wrote:
>>
>> El 20/07/2010 21:03, Mike Cowlishaw escribió:
>>
>> SHORT SUMMARY
>> =============
>>
>> Instances of dependent classes don't have privileged access to parent
>> objects' members but they should. In particular, private members are
>> inaccessible to them. This issue invalidates many common use patterns for
>> member classes. This access restriction is not documented anywhere but is in
>> fact enforced by the reference implementation's compiler.
>>
>> This memo proposes modification of the reference implementation so it
>> grants access to parent objects private members from dependent classes'
>> instances.
>>
>> Hmmm ... but then the private variables would no longer be private
>>
>> Why so? They wouldn't lose their 'privateness' any more than by being
>> accessible by member methods of the class (which of course they are).
>>
>> -- so changing/removing them could break subclasses.
>>
>> Again, why so? At which point did I propose to make them available to
>> subclasses? For this we already have inheritable
>>
>> Surely not good.
>>
>> I would agree if that had anything to do with what I'm proposing..
>>
>>   If they are visible to *any* other class they should be marked as such
>> (i.e., not PRIVATE)?
>>
>> private properties must not be accessible from anywhere outside their
>> defining class, agreed. But as a mater of fact member classes ('dependent
>> classes' in NetRexx parlance) are just that: members of the defining class.
>> You even implemented them like such!
>>
>> 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.
>>
>> Returning to the analogy of member methods. If you were to remove a
>> private property of a given class, of course you would need to update any
>> methods which accessed it, otherwise the program containing it wouldn't
>> compile. At no point in time subclasses would be affected in any way.
>> Similarly you would need to update any dependent classes (which by
>> requirement must be present in the same source file --'program' in NetRexx
>> parlance). No subclass is impacted. Not even any other class which happens
>> to use ours is impacted.
>>
>> Looking at it from another angle: a public dependent class is part of the
>> interface of the class from which it depends. A private dependent class is
>> part of the inner machinery of no concern for any code outside the parent
>> class. Of course both variants must be in sync with the parent class; a
>> requirement which is enforced by the fact that both class definitions must
>> reside at the same compilation unit. (again, just like member methods)
>>
>> PS .. is not the 'inheritable' visibility just what you are asking for?
>>
>>
>> Absolutely not!!
>> That would be worse than using shared. Exposing internal state of the
>> depended class not only to classes at the same package but also to
>> subclasses in any package.
>>
>> At this point I'm not sure whether I made a really poor job explaining
>> myself or you didn't get to read my previous note past the short summary
>> section...
>> Could you please point out for me how inheritable would alleviate in any
>> way any of the issues described under 'derived issues'?
>>
>> Inner classes on the jvm have privileged access to outer class members.
>> NetRexx, while trying to support this very feature of the jvm, chose to
>> change this policy; invalidating along the way most of the uses inner
>> classes were designed for in the first place.
>>
>> This boils down to: in order to hide internal estate to code which is in
>> fact inside the class, we are forced to expose internal state to code which
>> is outside the class. A very awkward way of adhering to the information
>> hiding OO principle IMHO...
>>
>>
>>
>>
>>
>> ---
>> Saludos / Kind regards.
>> David Requena
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 23/07/2010 0:17, Kermit Kiser escribió:

I can't follow this "dependent" vs "private" discussion since it has not impacted me personally yet, but I have two cents to add while we are discussing changes in this area. It seems to me that the main benefit of minor classes is that you can define them at the point they are used (in Java code that is). Putting them at the end of the parent class (as in NetRexx code) defeats most of the purpose for me. I would like to have an "End-Class" type of statement that allows dependent classes to be defined "inline". That way you could see what a "listener" does when looking at the code that sets it, like you can in Java. Anyone see problems with that?

Well, as it's turning out, it's not as much a 'dependent vs private' issue as an 'inner versus outer minor classes' one :-)

If I understand you right your asking about a third kind of inner classes (local classes) which NetRexx has never intended to support in any way.
I must admit that why 'The primary benefits of the local and anonymous inner classes are already available in NetRexx 1.1 as adapter classes' is way beyond my understanding though...

I agree some new syntax would be needed in other to support them but I think and 'End-Class' instruction would be quit inconsitent with the syntax used to define all other kinds of classes.

IMHO local and anonymous classes are OK for a two liner but most of the time are over-abused. While reading java code, nothing diverts more my attention from the code I'm actually studying than a sudden fifty-line class definition thrown at me.

---


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

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]