:Include doesn't include variables (or objects)?

[Erik.Friis]

In reading up on :Include I'd considered it be be sort of solution to the lack of multiple inheritance....I started to implement my classes with :Include and upon pressing Esc I was surprised that it doesn't include variables? I guess because unlike a function there is no way to place an :access specifier on a variable (field) and no way to create one yet without a value. Clearly it will become very important to be able to define a field (variable) in a namespace as well as a method....this will allow for the true unification of namespaces and classes as far as I can tell. Please give this some serious consideration Dyalog team as it will go a very long way!

[Erik.Friis]

In looking at the documentation for the extension to []NC - it would seem that it would be very beneficial to be able to define Fields and Properties directly in a namespace and allow them to be :include'd into a class. I see that sub-namespaces are not included, but how about classes that are defined in the namespace?

[alexbalako]

Hi Erik,
:Include is a control structure implementing []PATH.
[]PATH is similar to PATH in OS, which is also not giving you access to data files.
Problem of functions being accessed with []PATH lookup is namespace scope of function execution.
Functions executed with []PATH lookup will be executed not in current namespace but in function source namespace. It will have no access to private fields of a class.
With variables it will not be easy to identify if you want to create new variable in current namespace or want to modify existing variable found in another namespace referenced by []PATH.

However, It is easy to achieve functionality you are looking for, by using class Inheritance. Even so it does not work for namespaces.
(To have “partial” class/namespace implementation will be also nice)

[Erik.Friis]

Alex, Per our discussion in the hallway at work today, I created a function in my :include'd namespace called Me that simply returns []THIS and it returned the reference to the calling object (!) and NOT the namespace as you'd thought it would do. I am not convinced that :include is implemented using the underlying code for []PATH. I think fields and properties do not get included because there is currently no syntactic way to specify them. This needs to be changed soon so that you can declare a public/private field or property in a regular namespace such that it can be :include'd, otherwise :include is purposely crippled.

Another thing I discovered tonight is that you cannot assign a function to a field :( only a variable that is not declared using the :field control structure! I was surprised by this restriction that resulted in a SYNTAX ERROR. Dyalog is this a bug?

[DanB|Dyalog]

I will try to answer several questions here, starting with the first:

Multiple inheritance is not allowed in Dyalog (as in many other OO languages). Using :include is not the way to achieve this. To do that you would have to use interfaces.

Fields can have their ACCESS defined using the SHARED/PUBLIC specifications, e.g.
:field SHARED PUBLIC X
The field may not have a value assigned to it immediately. Its []NC value will be 2 but it will be undefined (just like a shared var before being assigned).

:Including namespaces is not like []PATH. It copies only the code (functions) in the class, variables and other namespaces/class are not (like []PATH variables are not dealt with).
Since no field or property can be defined in a namespace, none can be specified there. You do that in the class. :Included namespaces are ONLY for bringing in common or often used code (or simply to bring down the size of your class). All Object Oriented feature must be defined in the class. :including namespaces is a feature, that is the way it works, it is only to bring in CODE. There are technical reasons why variables are not inserted in classes but it won't help listing them here.

Adding :ACCESS statements to trad fns is allowed and permits defining permissions for them.

Hope this helps.

[Erik.Friis]

Multiple inheritance is not allowed in Dyalog (as in many other OO languages). Using :include is not the way to achieve this. To do that you would have to use interfaces.

Dan, This quote is from the on-line Dyalog documentation:

A Class may import methods from one or more plain Namespaces. This allows several Classes to share a common set of methods, and provides a degree of multiple inheritance.

:Include provides a degree of multiple inheritance. I have heard the claim regarding interfaces being a "safe" alternative to multiple inheritance and it "dreaded diamond" problem from the C# and Java folks but never seen a good example to back it up. An interface is analogous to an abstract base class in C++ consisting of ALL pure virtual functions (stubs, if you will). That means in every class that inherits the interface, you must write code for every
function in the interface, you might achieve polymorphism (late binding this way), but there is absolutely no code reuse with interfaces. I use inheritance at least partially (perhaps mostly) for code reuse in APL (APL used late binding everywhere anyway) and you can achieve a degree of polymorphism by passing a reference(s) to your "base" classes to circumvent the restriction on single inheritance.

So :include is a nice feature. You say there are technical reasons why properties and variables are not included with :include? There doesn't seem to be any good reason that I can think of other than the fact that you cannot syntactically define a field or a property directly in a namespace (yet)....this ability is important to have in future releases so :include will allow this.

[Morten|Dyalog]

One important reason why :Include does not include variables is that it raises the question of whether these variables should then be shared by all (instances of) the classes that included them. In the case of the code: If I include a function myns.foo in two classes, then it is "pretty obvious" that no matter whether I am editing myns, or tracing through a method call in one of the two including classes, I want to make a change which is shared by everyone.

In the case of variables, it does not seem at all "obvious" what (X←X+1) would mean, if X had been included from a namespace. One would need some kind of additional mechanism to declare whether (each?) variable should be completely shared, shared within each class, or copied into each instance and then be separated from the original. Or perhaps become a "read only" variable.

[Erik.Friis]

Morten,

From the on-line documentation:

When the Class is fixed by the editor or by ⎕FIX, all the defined functions and operators in Namespace NS are included as methods in the Class. The functions and operators which are brought in as methods from the namespace NS are treated exactly as if the source of each one had been included in the class script at the point of the :Include statement.

So why not do the same with fields? Each class "includes" in it's own instance of the field/property. If you want to share them then use the shared access control (similar to a static class member in C++). The :access control should be able to be set to public/private/shared in the namespace since this code is "included" and not inheritted. The only draw back I see with using :include is that (I'm assuming that) each class will have its own copy of each included function as opposed a pointer to the function under the covers, but perhaps this can be resolved too with some "special magic" if it hasn't been done so already.

[Morten|Dyalog]

The documentation is not telling the whole story: The included functions are treated as described from the point of view of usage, but there *is* special magic to ensure that there is only one copy of the source code. It would not make any sense to talk about including a namespace if the source code was only copied the first time you used it, and the class then had a private copy.

So all the functions are shared - but your proposal is that all variables should be "unshared". Changes to variables would NOT be reflected back to the namespace. This is certainly possible, I'd like to hear a few more opinions before we consider it seriously.

While on this topic: We are considering "tidying up loose OO ends" as a theme for v13.1, which we have just started planning. It would be interesting to hear well argued opinions from OO-experienced users about what the most important missing pieces are. Candidates might be:

1) The current proposal to :Include variables
2) Support for "protected" members
3) Support for Microsoft.Net "Generics"

If you would like to argue for any one of these, I suggest that you put together a post which clearly describes the benefits of the proposed feature, and a list of things you can't do because it is currently missing - and start a new thread in the OO forum titled "The Case For [... your proposal ...]".

This is NOT a promise to implement any of the above suggestions in 13.1 (or any other release).

[alexbalako]

Shame on me.
I have assumed too much and also learned now.
Thank you.