Nested classes

[Budgie]

Is there a good reason why I can't get hold of private methods, etc., from the parent class when I am in a nested class? I don't really want to give them public access, because they're not really public items.

[paulmansour]

I'm not sure of the answer, but for what it's worth:

This is a problem I have run into.

I think the proper term is "friendly" classes. You have a set of classes that are provided as a unit. These classes need to internally see, set, and manipulate each others private properties and methods. In other words, some members need to be public to other classes in a given set or group, but private to anything else. You might call these members semi-private.

I too thought nested classes in Dyalog might provide this but it does not. But even if it did, it doesn't really solve the problem, as you may have no hierarchy and nesting does not apply.

I get around this somwhat by naming conventions. I use ∆_Field and ∆Foo for semiprivate fields and methods respecticely. However this only works because I have control over the environment where they are called (that is, a domain specific scripting language) and can disallow use of delta. It does not help if you are providing functionality to other APL programmers, free to do what they want in a workspace.

[StefanoLanzavecchia]

People tend to have very strong opinions on the accessibility of methods/properties/fields in the different OO programming languages. Dyalog decided to have only to have only two levels: visible for all, completely private. Other languages have more nuances. For instance, in C# you have "internal" in addition to private and public. In C++ you have "protected" which is exactly what you (and I, to be honest) would like to see in Dyalog's OO extensions as well. I believe there are good reasons not to have it (why should a subclass be allowed access to implementations details otherwise hidden?), so I try to live without it.

[Budgie]

why should a subclass be allowed access to implementations details otherwise hidden?

In my case the class instance is a file, and the subclass instance is an index to that file. A single file can have multiple indexes. Index objects require access to file object details, but there is no reason for those details to be made available globally.

[Erik.Friis]

People tend to have very strong opinions on the accessibility of methods/properties/fields in the different OO programming languages. Dyalog decided to have only to have only two levels: visible for all, completely private. Other languages have more nuances. For instance, in C# you have "internal" in addition to private and public. In C++ you have "protected" which is exactly what you (and I, to be honest) would like to see in Dyalog's OO extensions as well. I believe there are good reasons not to have it (why should a subclass be allowed access to implementations details otherwise hidden?), so I try to live without it.

I think one of main reason for having a "protected" keyword would be for efficiency when creating a derived class - you get direct access to fields, which in general, should be private without having to go through a public get/set property and its associated overhead. It also has implications on naming conventions in my derived classes as typicially I start all of my field names with the prefix "My" to keep things straight. I access private field members directly from methods within the same class without going through properties. I think that it's clearly the right thing to have a "protected" attribute to give derived class implementors access to some fields that need to remain private to class "users."