APL-Journal - APL Germany e. V.

APL-Journal
Dyalog Version 11.0
Morten Kromberg
With the addition of classes and the ŒNEW system function
for creating instances of classes, version 11.0 is the first version
of Dyalog APL with core language support for writing
object oriented applications. However, objects are not entirely
new to Dyalog APL – the first objects appeared in the language
around 1990.
The first recognisable „objects“ were introduced into
Dyalog APL when the Windows GUI interface was added in
version 6.3 – in the early 1990’s. Apart from the word property
to describe a „variable which was a child of a GUI object“,
object terminology never really caught on in the APL
community – but whether we knew it or not, GUI elements
like forms, labels or buttons were in fact classes that the APL
developer could create instances of, and these instances had
properties and methods.
The new objects were created and manipulated using a set
of new system functions,ŒWC for the creation of objects,
ŒWG and ŒWS for getting and setting the value of properties,
and ŒNQ for triggering events and calling methods. The
original syntax required the names of objects and their members
to be given as strings. For example, the statement
'MyForm' ŒWS 'Caption' 'Hello World'
… would set the caption of MyForm. Over the next
few years, Dyalog APL learned to recognize COM and
Microsoft.Net classes and objects. Within APL, we were able
to create namespaces, which were objects in that they contained
collections of variables and functions. With namespaces came
the familiar (to some) dot notation which APL shares with
most other object-oriented languages, allowing the above
expression to be shortened to:
MyForm.Caption½'Hello World'
… which is an obvious improvement in terms of readability.
Finally, it was realized that references to objects could
be stored in arrays, and the dot notation could be extended
to allow nested name references, allowing expressions like:
Btns½MyForm.(Button1 Button2 Button3)
Btns.(Caption Posn)½
Ç('Save' 'Cancel' 'Help'),[1.5] 100,¨ ¯40+50×ì 3
Namespaces were different from other objects in that they
were not based on a class definition: Each namespace was
created empty and could be filled with anything the APL
developer desired. One could perhaps argue that this is „how
APL objects should be“, but there are situations where a
blueprint makes ideas clearer and solutions simpler. In particular,
we often want to share the same code between several
namespaces without actually having several copies of the
source code.
In addition to using objects within APL, the need for describing
APL components in terms which are easily understood
by users of other languages has become very important
as standards like COM and .Net have made it practical
to craft solutions from components written in more than
one language. Although it has been possible to do this in
Dyalog APL for several releases, it was clear that this could
become more straight-forward if it were possible to define
classes in APL.
The main feature of version 11.0 of Dyalog APL is the
introduction of classes as part of the APL language. Classes
can be used to create instances. In a nutshell, a class definition
defines the functions and variables which will be available
from within each instance of the class. For example, the following
class definition defines a class for which every instance
will contain the variables Name and Price (and sets
default values for them).
:Class Product
:Field Public Name½''
:Field Public Price½0
:EndClass
This allows:
APL - Journal 2006, 25. Jg., Heft 1/2 11