Abstract Classes and Visitor Patterns

[arcfide]

So, being new to OOP with Dyalog APL, I am wondering, is there a
convention for doing Abstract Classes in Dyalog? It seems that there are
only interfaces, is this correct?

Additionally, with patterns like the Visitor pattern, one normall
dispatches using the method dispatch system, which relies on the type
signature to dispatch on the type of node that it receives. In Dyaloag,
there are no such annotations, and so it seems like it would be hard to do
this. We could just do the dispatch ourselves using ⎕CLASS and :Select,
but is this the “best practice”?

[JohnD|Dyalog]

Hi,

An interesting couple of questions. I wasn't completely "up to speed" on the visitor model but I've had a very interesting hour or so catching up.

As you say, Dyalog does not have abstract classes, only interfaces. There are a number of additional OO features that we may add to the Dyalog implementation going forwards and abstract classes are on the list of things to be considered.

Dyalog has a :Signature statement to specify overloads for a method, but this only applies to emitted .Net metadata. For performance reasons (amongst others) we don't check the signatures in a plain APL OO application.

I found this article: http://weblogs.asp.net/cazzu/articles/25488.aspx particularly useful. I wonder if rather than using ⎕CLASS and :Select you could use different method names for each node (as per the example in that link, and listed below). I appreciate that it's not as elegant as using the overloads but it may be preferable to looking at ⎕CLASS.

Code: Select all

public interface IVisitor
{
   void VisitCustomer(Customer customer);
   void VisitOrder(Order order);
   void VisitItem(Item item);
}

Please let us/me know how you get on.

Best Regards,
John Daintree.

[arcfide]

Thanks for the response! I am not sure that I can use the multiple Visit methods approach, but maybe I just do not see it. In particular, this is the paper I am examining and seeing if I can adapt cleanly to Dyalog. Maybe it is just better to not do this with OOP?

http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf