[Enhancement proposal]: Dependent classes and access to parent object's members

[David Requena]

Hi All,

Here's yet another proposal for language enhancement for when/if NetRexx gets ever open sourced.

I'm sorry for a somewhat long email but I intend this to be the seed for some further debate on the subject. I'm trying to get the most ground laid out to start with.

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


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.

As discussed below, this:

- Wouldn't enter in conflict with current language specification in any way.
- Wouldn't break any pre-existing code.
- Would allow effective use of common use patterns for 'member classes' without breaking the OO principle of information hiding as the present situation forces us to.


(MOSTLY UN)DOCUMENTED BEHAVIOUR
===============================

As it stands, language documentation states 'Dependent classes have simplified access to their parent objects and their properties' (see notes 1 & 2).
These documents proceed to describe 'simplified access' as the ability to use some syntax sugar (namely the special word 'parent' and the form shortclassname.this) for accessing parent objects' properties and methods. Which level of privilege is granted to dependent classes' instances for access to members of their parent objects remains undocumented.

There is a 'Technical detail' document at the Library section of IBM's NetRexx website (see note 3) which briefly describes minor classes in general. This document states how dependent classes mirror java 1.1's concept of member classes and specifically how instances of them have 'privileged access' to their parent objects:

    "The rules for member classes are supported by the concept of a 'dependent class' - a minor class which has privileged access to the its parent object and its properties." (see note 4)

That last document is the only place I could find where the subject at hand is mentioned. It should be noted that being the case the language specification says nothing (implementation defined?), this document does not contradict the spec in any way.


IBM's NETREXX COMPILER CURRENT BEHAVIOUR
=======================================

The translator won't compile any code in which a method of a dependent class attempts to access a private member of its parent object.
As a sample (see note 5):

                class TestDependent
                          
                    properties private
                        privateProp = "private_property"
                      
                    method main(args=String[]) static
                        parentObject = TestDependent()
                        dependentObject = parentObject.DependentClass()
                        dependentObject.checkAccessToParentObject()
                      
                      
                class TestDependent.DependentClass private dependent
                      
                    method checkAccessToParentObject()
                        Say parent.privateProp

This code fails to compile with:

    "Error: The property 'TestDependent.privateProp' was found, but is not accessible from class 'TestDependent.DependentClass'"

In fact the maximum level of access granted is to shared members. In other words: the same as any other class in the same package.


DERIVED ISSUES
==============

In general the 'dependent class' feature departs from the java 1.1's 'member class' feature it intends to mirror

    "..., languages that are to take full advantage of the Java environment must support access to these classes (and, by implication, allow their definition)." (see note 3)

I'll be discussing here a couple of bad consequences of the issue in the context of awt/swing programming which I think is the most common use for this feature. No matter what, other frameworks are equally impacted by analogous reasons.

Inter-thread access to current object
-------------------------------------
The single most common use case for dependent classes is when modification of the current object is required to be performed from a different thread of execution. This could be because a call to a potentially blocking method is to be avoided in the current thread (perhaps in an event handler); or because modification of properties of the current object is to be done from a special thread (as when instantiating a swing UI from the AWTThread, or when updating that UI from threads other than the AWTThread)

As things stand now, you instantiate a dependent object which implements Runnable, run it (by starting a new thread in the former case, or calling EventQueue.invoqueLatter() in the latter), and let it operate in our members. BUT: we need to qualify accessed members at least as 'shared' for this to work.

In most cases this members are conceptually private but we need to open them at least to classes in the same package. So we have a case of information hiding not enforceable. The jvm won't prevent any user of our code to place his classes at our packages (in contrast with what it does with its own standard library ones)

An example of a specially grave consequence is that there is no way of instantiating a SWING UI in the way mandated by the framework specification (java 1.5 onwards). That is:

- Implement a private constructor
- Get it called from a Runnable started from the AWTThread (EventQueue.InvoqueLatter())
 
Our constructor will need to be qualified at least as 'shared' so we cannot grant that our UI will always be instantiated in a thread-safe manner.


Listener implementation
-----------------------
This is yet another very common use case although fortunately there are some workarounds (i.e. having our class directly implement any needed listener interfaces, not bothering with inner classes).

Here you instantiate a dependent object implementing a certain listener interface and register it so it gets called from the AWTThread in response to a given event. In most instances some modification on our internal state will ensue (say a click on a 'Cancel' button which will dismiss a currently visible dialog for instance).

Again the reference to our example dialog needs to be qualified at least shared if it to be accessed from our listener dependent object. But this reference should be a fully private object of no interest whatsoever to any other class; be it in the same package or not.


PROPOSAL
=====================

Lets modify the reference implementation and language specification (both when available) so access to private members of parent objects from dependent instances is explicitly granted.

Some factors to consider while evaluating proposal
--------------------------------------------------

Current language specification lacks information on either possibility while documentation at the language website strongly hints toward the option proposed here. Even when this proposal gets refused, specification should be revised to explicitly state chosen policy.

The 'dependent classes' feature fails to mirror the 'member classes' java feature as intended.
There is the most aggravating situation where currently is impossible in NetRexx to use an important java subsystem in the way mandated by its specification (swing ui instantiation from java 1.5 onwards)

It should be noted that no pre-existing code is to be broken by the proposed change as it'd be just lessening a current restriction.

While admittedly the feature is today an improvement over the packaging system alone, it lacks the single most useful trait of member classes. Namely, privileged access to parent object members. IMHO this renders the feature virtually useless.


ACKNOWLEDGEMENTS
================

Well, if YOU got that far reading this memo, I guess I should be sincerely grateful for your time.

MANY THANKS!  ;-)


NOTES
=====
1 - NetRexx Language Definition - Supplement (2.00) at http://www-01.ibm.com/software/awdtools/netrexx/library/nrsminor.html
2 - Mike's NetRexx 2 document, page 129, at http://speleotrove.com/misc/NetRexx2.pdf
3 - NetRexx Technical detail document at http://www-01.ibm.com/software/awdtools/netrexx/library/nrminor.html
4 - On this quote I substitutes italics emphasis on the original for single quotes in the term 1dependent class', no other edit was performed. In particular the apparent erratum in '... access to the its parent ...' is left as is in the original document.
5 - Please find this code as an nrx file at http://kenai.com/projects/netrexx-misc/downloads/download/misc%252FTestDependent.nrx.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

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]