Dyalog Forums

I'm not exactly a "newbie" but I've been away from APL for about 15 years now and am looking into the new OOP APL capabilities.

One of the features of OOP in c++ and some other languages is providing methods that determine how class objects behave under primitive operations. For example, if I have a class that represents a Unit of measure (meter/second, kg/meter*3, etc.) and I want to be able to determine the resulting Unit when I multiply or divide Units. If it is possible to override the behavior of the primitive operators, like in c++, then I could write something like this

uom1 ← ⎕NEW Unit ('meter/second' ... other initializing args)
uom2 ← ⎕NEW Unit ('second' ... other initializing args)

uom3 ← uom1 × uom2
⎕←uom3.Name
meter


where the implementation of the operator× for the Unit class would know enough to be able to do units-cancellation to arrive at the right answer. I have written such operators in c++. I was wondering if the OOP implemention in APL allows one to do something similar?

The short answer is "no", APL does not allow overriding primitive operations.

However, with some "fiddling" is *is* possible to achieve the behaviour for some of the overridable operations supported by .NET: I haven't actually tried this myself, but I believe that if you expose methods with the names in the table that you can find on page 19 of the Dyalog .NET Interface Guide http://docs.dyalog.com/13.0/Dyalog%20APL%20DotNet%20Interface%20Guide.v13.0.pdf, and export your class in a .NET assembly, then APL will call your methods for the (admittedly limited set) of functions in the list.

I don't really recommend this is a methodology for application-building at this point in time, but it might be fun to play with.

Why not institutionalize the role of overloading, instead of leaving it as a relatively obscure special feature? Since it already means APL has the overhead of checking every named object to see if it is special, it would be great if an expression like A = B would cause a lookup first of A.op_Equality(B), if op_Equality is defined, and otherwise take traditional next steps. Yes, these things can be abused, but they are so very useful where mathematical operations or metaphors are involved: Various kinds of biginteger, bigreal, or bignumber packages exist out there and they certainly would benefit from overloading, esp. compared to the more ad hoc alternatives, such as C←A +BIGINT B, where A and B are in (say) a BigInt class.

Oh yes, why not include all the possible overloaded functions available for, say, C#, omitting, perhaps, those that don't have a natural APL equivalent, such as dyadic ⌽?