Download - Object Oriented Programming in APL
Oct 2006 OOAPL 2
Introduction
• Interoperability & 64 bit OS
• New WS management
• New primitives & enhancements to others
• Object Orientation
V11 has been released.Here are the major features:
Oct 2006 OOAPL 3
This talk is based on 2 things:
1. Why? Why should I know about this? Why am I here?
2. OK, I’m still here, how do I use it?
Oct 2006 OOAPL 4
Synopsis
Why should I be here?I. Reasons
How do I use this?I. History of OOII. DefinitionsIII. The APL wayIV. Implementation details
Real Life Example (SJT)
Oct 2006 OOAPL 5
Reasons: why do this?
Because Object Orientation is a Valuable Tool of Thought!
To be able to Share Tools and Components more Easily
To help us Manage Complexity in all Project Phases
To use .Net more easily
Oct 2006 OOAPL 6
.Net was already in V10
The ability to use .Net with classes was already there in V10 but it was more difficult to use.
Oct 2006 OOAPL 7
History
OO is not new, it’s been around for a while.
Pretty much the same story as APL
50s: conception
60s: 1st implementation (SIMULA compiler)
70s: 1st user base, Smalltalk compiler
80s: into Eiffel to bridge the “gap”
90s: popularity grows (≠APL) thanks to C++ and Java
Oct 2006 OOAPL 8
The evolution of data
1. Elementary data elements (like int) and arrays of them (all the same)
2. Structures (like {i: int; d: date}), many elementary elements or structures (recurs)
3. Namespaces (structures whose elements are referred to by name)
4. Classes (namespaces with initializers & cleaners)
Oct 2006 OOAPL 9
Data in Dyalog APL (DYW)
In DYW all these objects exist.
You can often simulate one by another.
For ex: a table of names & values can represent a namespace of variables.
DYW can also store the OR of a ⎕namespace.
Oct 2006 OOAPL 10
The evolution of data
In traditional (procedural) systems, data is separated from code:
data
code
Oct 2006 OOAPL 11
The evolution of data
This is the same in traditional APL systems, data is separated from code:
Oct 2006 OOAPL 12
The evolution of data
In OO systems, data is more tightly coupled with code:
privatecode
data
privatecode
data
Do this
Do that
Oct 2006 OOAPL 13
The evolution of data
In OO APL systems, data is also tightly coupled with code but in a more procedural manner:
privatecode
data
privatecode
data
Oct 2006 OOAPL 15
OO fundamental concepts
The Object Oriented paradigm is based on:
1.Classes2.Instances 3.Members4.Message passing5.Inheritance6.Encapsulation7.Polymorphism
Oct 2006 OOAPL 16
OO fundamental concepts
1. ClassesA class defines the abstract characteristics of
a thing, akin to a blueprint.
It describes a collection of variables and methods (functions), possibly with a constructor method that can be used to create objects of the class and a destructor to remove the objects thus created.
Oct 2006 OOAPL 17
OO fundamental concepts
ClassesA class can implement one or more
interfaces.
An interface describes what it should do.
The class describes how it should be done.
If a class implements an interface it should do it completely, no partial implementation is allowed.
Oct 2006 OOAPL 18
Interfaces - example
The following maneuvering interface describes what has to be done with a machine:
Method Steer (direction); // where to go
Method Accellerate (power); // go faster
Method SlowDown (strength); // go slower
It does NOT specify how it should be done.
Oct 2006 OOAPL 19
Interfaces - example
This car object implements maneuvering:
Class car : maneuvering;Method SteeringWheel: implements maneuvering.Steer (turn); ...Method GasPedal: implements maneuvering.Accellerate (push); ...Method BreakPedal: implements maneuvering.SlowDown (hit); ...
Oct 2006 OOAPL 20
Interfaces - example
This plane object implements maneuvering:
Class plane : maneuvering;Method Stick: implements maneuvering.Steer (move); ...Method Handle: implements maneuvering.Accellerate (pushpull); ...Method Flaps: implements maneuvering.SlowDown (degree); ...
Oct 2006 OOAPL 21
OO fundamental concepts
2. InstancesThose are tangible objects created from a
specific class.
Upon creation any specific action is carried out by the constructor of the class if need be.
Upon destruction, the destructor is responsible for cleaning up.
Oct 2006 OOAPL 22
OO fundamental concepts
3. MembersThis is the code and the data of a class.
The code is divided into Methods (functions) and data is divided into Fields (variables).
There are also Properties which are Fields implemented via functions to read/set them.
All these are visible from outside when Public or invisible from outside if Private.
Oct 2006 OOAPL 23
OO fundamental concepts
Members: MethodsThose can either reside in the class
(shared method) or in the instance (instance method).
There are also abstract methods (e.g. in interfaces) with no code, only calling syntax.
Constructors and destructors are methods.
Oct 2006 OOAPL 24
OO fundamental concepts
Members: FieldsThose can either reside in the class
(shared field) or in the instance (instance field).
They can also be read only.
Oct 2006 OOAPL 25
OO fundamental concepts
Members: PropertiesThose are Fields implemented by
accessing methods, i.e.
PropX←value is implemented by
SET value
They can either reside in the class (shared property) or in the instance (instance property).
Oct 2006 OOAPL 26
OO fundamental concepts
4. Message passingThis is the (usually asynchronous) sending
(often by copy) of a data item to a communication endpoint (process, thread, socket, etc.).
In procedural languages it corresponds to a call made to a routine.
Oct 2006 OOAPL 27
OO fundamental concepts
5. InheritanceThis is a way to avoid rewriting code by writing
general classes and classes that derive from them and inherit their members.
This helps achieve reusability, a cornerstone of OO.
Oct 2006 OOAPL 28
OO fundamental concepts
Inheritance
We say that a (derived) class is based on another one.
All classes (but one) are derived from another one or by System.Object (the default)
Oct 2006 OOAPL 29
OO fundamental concepts
Inheritance: Based classes (reusability)
A class can be based on another based class. See class Collie based on Dog based on Animal
Animal
Dog: Animal
Rex (Collie)Fish: Animal
Fido (Collie)
Big Dane: Dog
Collie: Dog
Instances
Classes
Oct 2006 OOAPL 30
OO fundamental concepts
InheritanceWhen an instance is created from a class
based on another one it inherits all its members automatically.
Members can be redefined but subroutines must be specifically set to override base class subroutines.
Oct 2006 OOAPL 31
OO fundamental concepts
Inheritance: multiple inheritance
A class can be based on several other classes. See class Mule made out of 2 different classes.
Horse
Donkey
Mule
Oct 2006 OOAPL 32
Override concept
// M1 calls its own M2:(NEW A).M1
I am A
// M1 calls its own M2:(NEW B).M1
I am B
M1
M2 M2‘I am A’
M1
M2 M2‘I am B’
Class A Class B
Oct 2006 OOAPL 33
Based classes
// M1 calls its own M2:(NEW A).M1
I am A
// M1 calls its own M2:(NEW B).M1
I am A
M1
M2 M2‘I am A’
There is no M1 in Bso A’s (on which B is based) M1 is used
M2‘I am B’
Class A Class B: A
Oct 2006 OOAPL 34
Based classes
M1
M2 M2‘I am A’
There is no M1 in Bso A’s (on which B is based) M1 is used
M2: Override‘I am B’
Class A Class B: A
// M1 calls its own M2:(NEW A).M1
I am A
// M1 calls its own M2:(NEW B).M1
I am A
A:M2 does not allow to be overriden
Oct 2006 OOAPL 35
M2: Override‘I am B’
Based classes
M1
M2:Overridable
M2‘I am A’
Class A Class B: A
There is no M1 in Bso A’s (on which B is based) M1 is used
// M1 calls its own M2:(NEW A).M1
I am A
// M1 calls its own M2:(NEW B).M1
I am B
A:M2 does allow to be overriden AND B wants to override it
Oct 2006 OOAPL 36
OO fundamental concepts
6. Encapsulation• Hides the underlying functionality.• It conceals the exact details of how a
particular class works from objects (external or internal) that use its code.
• This allows to modify the internal implementation of a class without requiring changes to its services (i.e. methods).
Oct 2006 OOAPL 37
Example: a car
Consider a car: the functionality is hidden, it is encapsulated, you don’t see all the wiring inside, you’re only given specific controls to manipulate the car.
Oct 2006 OOAPL 38
Encapsulation
To allow access to a member there are various level definitions.
For example, to expose a member you must use some syntax that will declare it public.
By default, private is the norm.
Oct 2006 OOAPL 39
OO fundamental concepts
Encapsulation: privateA private member cannot be seen from
anywhere. Only other Methods can access it from inside the class if private shared or from within the instance if private instance.
M is onlyseen in thepale area
sub1
sub2
Oct 2006 OOAPL 40
OO fundamental concepts
Encapsulation: protectedA protected member can only be seen from
within the instance of from within instances within it.
M is onlyseen in thepale area
sub1
sub2
Oct 2006 OOAPL 41
OO fundamental concepts
Encapsulation: publicA public member can be seen from anywhere.
All Methods can access it from anywhere whether it is public shared or public instance.
M is seenin all thepale area
sub1
sub2
Oct 2006 OOAPL 42
OO fundamental concepts
Encapsulation: friendA class declared friend can see the offerer’s
private and public members.
Private Pv
Public Pu
Friend A
Class A Class B
Private AvPublic Au
Here A sees B’s membersas its own members
Oct 2006 OOAPL 43
OO fundamental concepts
7. PolymorphismIt is behavior that allows a single definition to
be used with different types of data.
This is a way to call various sections of code using the same name.
Typed languages can tell the difference by looking at the “signature” of the functions (their number of arguments and their types)
Oct 2006 OOAPL 44
OO fundamental concepts
Polymorphism example
Foo (integer arg){// fn called with// an integer argPrint “Int arg”}
Foo (string arg){// fn called with// a string argPrint “String arg”}
Same function name, different code
Oct 2006 OOAPL 45
OO fundamental concepts
Polymorphism
A program that accepts multiple definitionsis said to be overloaded.
Sometimes arguments have to be coerced into a new type to achieve proper behaviour.
Oct 2006 OOAPL 46
OO Concepts Summary
• OO is based on +-7 key concepts
• Classes are blueprints
• Instances are objects created from classes
• They contain members (data & code)
• Their access is restricted
• The relation between classes is based on inheritance or specific access
Oct 2006 OOAPL 49
Implementation
• Dyalog follows C# rules closely
• The extensions to the language have been made in following with the :Keywords scheme introduced in the 90s (All new keywords start with ‘:’ )
• Some new system functions have been added and
• Some new system commands also
Oct 2006 OOAPL 50
Implementation
Let’s see how Dyalog APL does this:
1.Classes2.Instances 3.Members4.Message passing5.Inheritance6.Encapsulation7.Polymorphism
Oct 2006 OOAPL 51
Implementation: classes
A class can be defined using the )EDitor as in
)ED ○ MyClass
Upon exiting, MyClass will be defined in the current namespace (e.g. #)
Oct 2006 OOAPL 52
Implementation: classes
In the workspace MyClass appears as a namespace:
⎕NC ‘MyClass’
9
)CLASSES
MyClass
Oct 2006 OOAPL 53
Implementation: members
The members in a class are:• Field: same as a variable• Method: same as a function• Property: looks and feels like a variable but
implemented as a pair of functions
All can be either public or private (the default)
Oct 2006 OOAPL 54
Implementation: members
The class to the right shows a few fields (vars) and their access.
The access is the same for methods (fns) and properties.
Oct 2006 OOAPL 55
Implementation: members
The class to the right shows a few methods (fns) and their access.
The <mon1> is also used as a constructor. It MUST be public.
Oct 2006 OOAPL 56
Implementation: members
The class to the right shows 2 properties and their access.
The 1st one is private and readonly (it has no set fn)
The 2nd one is public read/write
Oct 2006 OOAPL 57
Classes are like blueprints: they define how things should be.
⎕NEW is a new system function that creates an object using a class as an instance.
Whatever is in the class will appear in the instance as a copy, not a reference
Implementation: instances
Oct 2006 OOAPL 58
⎕NEW accepts a one or two elements argument.
The 1st one is the class (not its name)
The 2nd, if present, is what to start/initialize it with. It can only be supplied if the class accepts a value as initializer.
Implementation: NEW⎕
Oct 2006 OOAPL 59
Example:
myInstance← NEW MyClass⎕The display form includes [brackets] by default
myInstance
#.[MyClass]
It is another type of namespace
⎕NC ‘myInstance’
9
Implementation: NEW⎕
Oct 2006 OOAPL 60
Classes may require something to initialize the instance. Ex:
)ED ○ Animal
Implementation: constructors
Here an animal mustbe have at least twocharacteristics:1.# of legs2. the sounds it makes
Oct 2006 OOAPL 61
Several instances can be made up of the same Animal class:
Implementation: constructors
After runningthis functionwe have:
)obsfish monkey myInstance snake tiger Animal MyClass
⎕NC ‘animals’ this is a variable holding 4 instances⍝2
animals.Nlegs how many legs for each animal?⍝4 0 0 2
Oct 2006 OOAPL 62
Implementation: message passing
In APL this merely consists in calling the methods directly either from the instance or from the class if shared, e.g.
Myclass.sharedFn args
or
myInstance.Fn args if any⍝
Oct 2006 OOAPL 63
Implementation: inheritance
Inheritance: Based classes
A class can be based on another based class. See class Collie based on Dog based on Animal
Animal
Dog: Animal
Rex (Collie)Fish: Animal
Fido (Collie)
Big Dane: Dog
Collie: Dog
Instances
Classes
Oct 2006 OOAPL 64
Example: a bird’s generic description is ‘plain Bird’
Birdy← NEW Bird⎕
Birdy.Desc
plain Bird
Implementation: inheritance
Bird Birdy (Bird)
When Birdy is created, Bird’s constructor is called
Oct 2006 OOAPL 65
Example: a parrot is a bird
Coco← NEW Parrot⎕Coco.Desc
Not a plain Bird, a Parrot
Implementation: inheritance
Bird
Birdy (Bird)
Parrot: Bird Coco (Parrot)
Oct 2006 OOAPL 66
We can create classes and instances at all levels
Implementation: inheritance
Bird
Parrot: Bird
Tweety (Macaw)
Macaw: Parrot
InstancesClasses
Birdy (Bird)
Coco (Parrot)
Oct 2006 OOAPL 67
Implementation: inheritance
Inheritance: constructors with arguments
Using the animal kingdom as example.
Animal
Dog: Animal
Rex (Collie)Fish: Animal
Fido (Collie)
Big Dane: Dog
Collie: Dog
Instances
Classes
Oct 2006 OOAPL 68
Implementation: inheritance
pet← NEW Collie ‘Rex’⎕pet. nl -2⎕
Name Nlegs Sounds Typepet.(Name Type)
Rex canis familiaris
Oct 2006 OOAPL 69
Implementation: inheritance
pet← NEW Collie ‘Rex’⎕pet. nl -2⎕
Name Nlegs Sounds Typepet.(Name Type)
Rex canis familiaris
Oct 2006 OOAPL 70
Implementation: Encapsulation
Conceals the exact details of how a particular class works from objects that use its code.
To allow access to a member there are various access level definitions.
Oct 2006 OOAPL 71
To expose a member you must make it public
For a property or a method (fn) you must use the :Access public Statement
For a field (var) you must use this statement:
:Field public MyField
Implementation: Encapsulation
Oct 2006 OOAPL 72
The class to the right shows a few fields (vars) and their access.
The access is the same for methods (fns) and properties.
Implementation: Encapsulation
Oct 2006 OOAPL 73
Shared vs instance
Each instance gets a copy of each member.
If a Field is shared it is kept in the class for all instances to see (and used)
Implementation: Encapsulation
Oct 2006 OOAPL 74
Shared vs instance
Example: keepCount
Here each instance has its own private ID and public name
The class keeps track of the number of instances created privately.
Implementation: Encapsulation
Oct 2006 OOAPL 75
Shared vs instance in1← new keepCount⎕
I am XYZ1 in2← new keepCount⎕I am XYZ2 in3← new keepCount⎕I am XYZ3 keepCount.Count3 keepCount. nl-2⎕ Count in2. nl-2⎕ Count MyName in1.Count3
Implementation: Encapsulation
Oct 2006 OOAPL 76
In APL a function CANNOT have different definitions using a single name.
OTOH, a constructor MAY have several definitions.
Since APL is typeless the only way to tell which function to use is by the NUMBER of arguments, from 0 (niladic) to any number.
Implementation: Polymorphism
Oct 2006 OOAPL 77
:Class manyCtors ∇ general x ⍝ This ctor any arg ⍝ It can be anything :Implements constructor :Access public ∇ ∇ nil ⍝ This ctor takes no arg :Implements constructor :Access public ∇ ∇ mon1(a1) ⍝ This ctor takes 1 arg ⍝ It MUST be a vector :Implements constructor :Access public ∇ ∇ mon5(a1 a2 a3 a4 a5) ⍝ This ctor takes 5 arg ⍝ It MUST be exactly 5 :Implements constructor :Access public ∇:EndClass
Implementation: Polymorphism
Example:
Depending on the number of arguments, the proper fn will be used.
Oct 2006 OOAPL 78
Implementation summary
• Dyalog follows C# rules closely
• )ED to edit classes
• classes are much like namespaces
• their members (vars & fns) cannot all be accessed
• []NEW makes an instance
• classes can be based on another one
• they use constructors to initialize them
Oct 2006 OOAPL 81
Implementation details
There is a lot more that has been implemented.
Dyalog APL uncovered new territory when venturing into OO.
In keeping with the dynamic nature of APL a lot of questions were raised.
And many were answered.
Oct 2006 OOAPL 82
Implementation details
Classes: new system functions/commands
• )ED ○name (circle to edit a new class)
• ⎕SRC: Just like NR returns a function in ⎕nested form, SRC will return the ⎕representation of a class in nested form.
• ⎕FIX: Just like FX creates a function, FIX ⎕ ⎕creates a class.
Oct 2006 OOAPL 83
Implementation details
Classes: new system functions/commands
• ⎕CLASSES returns the tree of references• )CLASSES lists all classes in the namespace• )ED ns/○cl/ interf;⍟ ∘ ns can contain classes• ⎕DF allows to alter the display of a class
(any namespace)• A class can implement an Interface• )INTERFACES lists all interfaces in the namespace
Oct 2006 OOAPL 84
Classes:
A class can implement one or more interfaces.
An interface describes what it should do.
The class describes how it should be done.
Implementation details
Oct 2006 OOAPL 85
This maneuvering interface describes what has to be done with a machine:
)ed maneuvering∘
It does NOT specify
how it should be
done.
Implementation details
Oct 2006 OOAPL 86
This car class implements maneuvering:
Implementation details
VW← new Car⎕ VW.GasPedal 60 Going up to 60 (maneuvering class VW).Steer 140⎕Heading NW (maneuvering class VW).Accellerate 120⎕Going up to 120 VW.GasPedal 100 Going down to 100 VW.BreakPedal 1 Breaking...
Oct 2006 OOAPL 87
This plane class implements maneuvering:
Implementation details
C172← new Plane⎕ C172.Stick 23 Heading 20 C172.Handle 200 Going up to 200 C172.Stick 23 11 Climbing, Heading 20 (maneuvering class C172).Steer 210⎕Heading 210 (maneuvering class C172).SlowDown 20⎕Flaps 20 degrees
Oct 2006 OOAPL 88
Implementation details
Members: new system functions/commands
• Can be another nested class (but not a ns)• ⎕INSTANCES lists the instances of a class• ⎕NEW creates an instance
• Triggers
• Special Property cases
Oct 2006 OOAPL 89
Implementation details
PropertiesIn other languages they are implemented as a pair of
functions.
In APL this simple case is handled naturally. It is called the SIMPLE case and is the default.
A 2nd case where indexing is made using any object (as opposed to numbers) is also handled easily. This is the KEYED case.
The array nature of APL introduced a notion of NUMBERED property. This is the 3rd case.
Oct 2006 OOAPL 90
Implementation details
Properties: SIMPLE caseWhen a property is set,
its SET function is called.
When retrieved, its GET
function is called.
‘pa’ is a namespace containing
the name of the property
(Name) and its value
(NewValue).
Oct 2006 OOAPL 91
Implementation details
Properties: KEYED caseThe set/get function call is made.
‘pa’ is a namespace also containing the indices of the property (Indexers).
Pk MUST be used with [brackets] and their contents cannot be elided.
Their shape must conform to APL rules for assignment and result.
Oct 2006 OOAPL 92
Implementation details
Properties: NUMBERED caseThe set/get function call is made,
ONCE per index.
‘pa’ is a namespace also containing the index to deal with (Indexers).
Pn may be used with indices. The SHAPE fn is used to check and generate indices.
Their shape must conform to APL rules for assignment and result.
Oct 2006 OOAPL 93
Implementation details
Default PropertiesThere can be only one.
If a default property exist, [indexing] can be done directly on the instance. Doing
inst[index] is the same as
inst.defProp[index]
If a property is the default then using “squad indexing” applies to the whole property
Oct 2006 OOAPL 94
Triggers
t← NEW trigger1 ('Daniel' 'Baronet')⎕Full name is Daniel Baronet
Full name is Daniel Baronet
t.FirstName←'Dan'
Full name is Dan Baronet
Implementation details
Oct 2006 OOAPL 95
Implementation details
Inheritance: new system functions/commands• :Based used to call base class constructor• ⎕BASE used to call base class functions• override/able• Destructors are called when the instance is destroyed• ⎕NC/ NL have been extended⎕• ⎕THIS is the same as ( NS’’).##⎕• :implements, :access• can be GUI based (ex: :Class F: ‘form’)• :include
Oct 2006 OOAPL 96
pet← NEW Collie ‘Rex’⎕pet. nl -2⎕
Name Nlegs Sounds Typepet.(Name Type)
Rex canis familiaris
Implementation details: :Base
Oct 2006 OOAPL 97
⎕Base is used to call base function like :base is used to call the constructor with an argument.This is used when the base function is shadowed by a class member. As in
in1← new derivedClass⎕in1.sqr 20
400
Implementation details: Base⎕
Oct 2006 OOAPL 98
Override and overridable
These concepts allow a base class code to be overridden.
The following slides will attempt to explain this in more details.
Implementation details
Oct 2006 OOAPL 99
Non-Based classes
⍝ M1 calls its own M2:( NEW A).M1⎕
I am A
⍝ M1 calls its own M2:( NEW B).M1⎕
I am B
Oct 2006 OOAPL 100
Non-Based classes
⍝ M1 calls its own M2:( NEW A).M1⎕
I am A
⍝ M1 calls its own M2:( NEW B).M1⎕
I am B
M1
M2 M2‘I am A’
M1
M2 M2‘I am B’
Class A Class B
Oct 2006 OOAPL 101
Based classes
⍝ M1 calls its own M2: ( NEW A).M1⎕
I am A
⍝ M1 calls its own M2:( NEW B).M1⎕
I am A
Oct 2006 OOAPL 102
Based classes
⍝ M1 calls its own M2:( NEW A).M1⎕
I am A
⍝ M1 calls its own M2:( NEW B).M1⎕
I am A
M1
M2 M2‘I am A’
There is no M1 in Bso A’s (on which B is based) M1 is used
M2‘I am B’
Class A Class B: A
Oct 2006 OOAPL 103
Overridden classes
⍝ M1 calls its own M2: ( NEW A).M1⎕
I am A
⍝ M1 calls its own M2 because ⍝ it has not been overridden:
( NEW B).M1⎕I am A
Oct 2006 OOAPL 104
Based classes
⍝ M1 calls its own M2:( NEW A).M1⎕
I am A
⍝ M1 calls its own M2:( NEW B).M1⎕
I am A
M1
M2 M2‘I am A’
There is no M1 in Bso A’s (on which B is based) M1 is used
M2‘I am B’
Class A Class B: A
Oct 2006 OOAPL 105
Overridden classes
⍝ M1 calls its own M2: ( NEW A).M1⎕
I am A
⍝ M1 calls B’s M2 because ⍝ it has been overridden:
( NEW B).M1⎕I am B
Oct 2006 OOAPL 106
M2‘I am B’
Based classes
⍝ M1 calls its own M2:( NEW A).M1⎕
I am A
⍝ M1 calls B’s M2:( NEW B).M1⎕
I am B
M1
M2 M2‘I am A’
Class A
There is no M1 in Bso A’s (on which B is based) M1 is used
Class B: A
Oct 2006 OOAPL 107
Implementation details
DestructorsThey are used to clean-up after
an instance is destroyed:
KingLear← new life 'Lear'⎕ King Lear is born
)erase KingLear
Lear is dead, long live the king.
Oct 2006 OOAPL 108
Implementation details: NC/ NL ⎕ ⎕
⎕NC/ NL extensions⎕
Those 2 system functions have been extended to deal with the new objects.
Since classes and instances are a type of namespace their basic classification is 9:⎕NC ‘myClass’
9To find their sub-class they need to be enclosed:⎕NC ⊂‘myClass’
9.4
Oct 2006 OOAPL 109
Implementation details: NC/ NL ⎕ ⎕
⎕NC/ NL extensions⎕
⎕NL has also been extended to report all objects of a given sub-class:⍴⍴⎕NL 9.4
2
Furthermore, if one of the argument to NL is negative ⎕the result is returned in vector format:⍴⍴⎕NL -9.4
1
Oct 2006 OOAPL 110
Implementation details: NC/ NL ⎕ ⎕
⎕NC/ NL extensions⎕
⎕NL and NC are symmetric such that⎕
n NC NL |n∊⎕ ⎕and
vn NL- NC¨vn vn is a list of names∊⎕ ⎕ ⍝
Oct 2006 OOAPL 111
Implementation details: NC/ NL ⎕ ⎕
⎕NC/ NL extensions⎕
⎕NL and NC also apply to variables and functions.⎕The complete list is:
2 3/4 9 n.1 Variable Traditional fn/op NS created by
NS ⎕ n.2 Field D-fns or –op Instance (could be form) n.3 Property Derived/Primitive - n.4 - - Class n.5 - - Interface n.6 External/shared External External Class n.7 - - External Interface
Oct 2006 OOAPL 112
Implementation details: NC/ NL ⎕ ⎕
⎕NC/ NL extensions⎕
⎕NL also reports instance members when used with a negative argument
instance. NL -2⎕ .1 report all fields⍝
Oct 2006 OOAPL 113
Types of Namespaces and their NC⎕The 1st two already existed in V10
• Regular NS 9.1
• Forms 9.2
• Instances 9.2 (NOT 9.3!)
• Classes 9.4
• Interfaces 9.5
Implementation details
Oct 2006 OOAPL 114
Implementation details: DF⎕
The default display form of a namespace is its path:
+‘t1.s1’ NS ‘’⎕#.t1.s1
We can change this using DF:⎕t1.s1. df ‘(S1: son of t1)’⎕t1.s1
(S1: son of t1)
Oct 2006 OOAPL 115
Display form of namespaces
abc←t1.s1 even if assigned a new name:⍝abc what does this look like?⍝
(S1: son of t1)abc≡t1.s1 it “remembers” its reference⍝
1≡⍬ ⍴abc it is still just a ref⍝
1⍴⍕abc its display has a length⍝
15
Oct 2006 OOAPL 116
Contents of namespaces
t1.s1.v11←’var’ If we change the ⍝t1.s1. fx ‘f1’ ‘...’ contents of s1:⎕ ⍝,t1.s1. nl 2 3⎕
f1 v11
,abc. nl 2 3⎕ abc will “see” it⍝f1 v11
⎕NC ’abc’ ‘t1’ ‘t1.s1’
9.1 9.1 9.1
Oct 2006 OOAPL 117
Contents of namespaces
To get a distinct copy of t1.s1 we need to doabc← NS OR ‘t1.s1’⎕ ⎕,abc. NL 2 3 everything is ⎕ ⍝ copied
f1 v11abc even its name⍝
(S1: son of t1)abc≡t1.s1 but they’re different⍝
0abc. fd ‘I am ABC’ abc⎕ ⋄
I am ABC
Oct 2006 OOAPL 118
Contents of namespaces
Outside world (e.g. WS) abc
I am ABC
∇f1...∇
v11←’var’
abc. NL 2 3⎕
f1v11
Oct 2006 OOAPL 119
Contents of namespaces
abc
I am ABC
∇f1...∇
v11←’var’
∇tx←{,⍵} ∇
You can addto a namespace:
tx←{, }⍵ ‘abc’ ns ‘tx’⎕
and <tx> appearswithout ‘v11’ or <f1>going away.
Oct 2006 OOAPL 120
Contents of namespaces
abc
#.[Namespace]
∇tx←{,⍵} ∇
But if you use ← instead:
tx←{, }⍵ abc← ns ‘tx’⎕
<tx> appears in‘abc’ alone andthe display form is reset
Oct 2006 OOAPL 121
Display form of a Form
The default display form of a Form is its path, just like a namespace:
+‘F1’ WC ‘form’ ⎕#.F1
We can change this using DF:⎕F1. df ‘<F1 is in great form>’⎕F1
<F1 is in great form>
Oct 2006 OOAPL 122
Display form of a form
⍝ we can add items to it:
‘F1.b1’ wc ‘button’⎕‘e2’ F1. wc ‘edit’⎕⎕nc ‘F1’ ‘F1.b1’ ‘F1.e2’
9.2 9.2 9.2
⍝ we have 3 instances of built-in APL forms
F1.e2 F1 each with its own name⍝#.F1.e2 <F1 is in great form>
Oct 2006 OOAPL 123
Contents of a form
The form contains 2 objects:←⍴⎕ ⎕nl 2 3 9
b1e22 2⎕nc ‘b1’
9⎕nc ‘Caption’
0
<F1 is in great form>
e2
Oct 2006 OOAPL 124
Contents of a form
A form is pretty much like a namespace.
It can contain variables and functions.
F1.v1←’some var’
F1. fx ‘f1’ ‘whatever’⎕F1. nl 2 3 these are POSITIVE numbers⎕ ⍝
f1
v1
Those are the items WE have added.
Oct 2006 OOAPL 125
Contents of a form
The form now contains 4 objects:←⍴⎕ F1. nl 2 3 9⎕
b1e2f1v14 2⎕nc ‘F1.b1’
9
<F1 is in great form>
e2
∇ f1whatever∇
v1←’some var’
Oct 2006 OOAPL 126
Contents of a form
BUT a form also has properties and methods:
F1. wx←1 to be able to see them⎕ ⍝←⍴⎕ F1. nl -2 3⎕
Accelerator ... Caption ... YRange
65
F1. nc ⎕ ⊂’Caption’ Caption is external⍝¯2.6
Those are the only visible members inside the form. They do NOT appear in nl +2 3⎕
Oct 2006 OOAPL 127
Contents of a form
The form has 2 types of functions and variables:
1. Those internal and specific to its type2. Those external, those we add
The 1st ones can be listed with a NEGATIVE NL ⎕argument
The 2nd ones can be listed with a POSITIVE NL ⎕argument
Oct 2006 OOAPL 128
Contents of namespaces
All namespaces have a common structure
• They inherit system variables• The system variables exist both internally
AND externally
Oct 2006 OOAPL 129
Contents of a form
If we redefine the form all external objects disappear:
+‘F1’ wc’form’⎕#.F1
⍴F1. nl 2 3⎕0 0
⍴F1. nl-2 3⎕65
#.F1
Oct 2006 OOAPL 130
Contents of a class
Outside world (e.g. WS) ShrIns
Classes are a different kind of namespace but they behave identically.
⍝ NO external object ⍴ShrIns. NL 2 3⎕0 0
Oct 2006 OOAPL 131
Contents of a class
Outside world (e.g. WS) ShrIns
Master Share/instance
∇MS1∇
FS1 (no value)
ShrIns. NL -2 3⎕FS1 MS1
The private members cannot be seen or accessed from outside.
∇MS0∇
FS0 (no value)
Oct 2006 OOAPL 132
Contents of a class
Outside world (e.g. WS) ShrIns
Master Share/instance
∇MS1∇
FS1 (no value)
You can add items “outside” a class: tx←{, }⍵ ‘ShrIns’ ns ‘tx’⎕ ShrIns.v11←32and they appearwithout anything elsegoing away.
v11←32
∇tx←{,⍵}∇
Oct 2006 OOAPL 133
Contents of a class
Outside world (e.g. WS) ShrIns
Master Share/instance
∇MS1∇
FS1 (no value)
ShrIns. NC 2 3⎕txv11 ShrIns. nc-2 3⎕ tx v11 FS1 MS1
v11←32
∇tx←{,⍵}∇
Oct 2006 OOAPL 134
Contents of an instance
Outside world (e.g. WS) SI1
#.[ShrIns]
∇MS1∇
FS1(no value)
SI1← new ShrIns⎕ ⍴SI1. NL 3 2⎕0 0 SI1. NL -3 2⎕ FI1 FS1 MI1 MS1
The shared members are visible through the instance.
∇MI1∇
FI1(no value)
Instancemembers
Classmembers
Oct 2006 OOAPL 135
Contents of an interface
Outside world (e.g. WS)
)ed maneuvering∘
⍴maneuvering. NC -2 3⎕0 maneuvering.v11←12 maneuvering. NC -2 3⎕v11
Oct 2006 OOAPL 136
Contents of an interface
Outside world (e.g. WS)
The methods in the interface can only be seen when exposed through the dyadic CLASS ⎕system function:
VW← new Car⎕ (VW class maneuvering). nl -3⎕ ⎕Accellerate SlowDown Steer
Oct 2006 OOAPL 137
:Include
This statement is used when wanting to include CODE (not data) into a class.
This may be because the code to include is common.
Oct 2006 OOAPL 138
Implementation details summary
• Many new system commands & fns• Interfaces show how it is done• Numbered Properties are implemented in a
special manner in APL• Triggers offer lightweight properties• ⎕NL/ NC have been extended⎕• The notion of external names is important• Inclusion of common code is possible
Oct 2006 OOAPL 141
Complex Class
This class is used to create complex numbers.
It can perform most simple math operations on them.
This class has • 2 public instance fields• 1 public shared field• 2 private fields• 5 instance functions• ...
Oct 2006 OOAPL 142
Complex Class
This class also has • 5 shared functions
These perform the basic operations: + × ÷ *
Oct 2006 OOAPL 143
Complex Class
This class also has • 2 constructors and• 2 private functionsone of which is a trigger
for when one of the fields is modified
Oct 2006 OOAPL 144
Keyed component file
The idea is to have a file whose components are accessed by key instead of a number.
Sort of
file.Read ‘key’
Oct 2006 OOAPL 145
Keyed component file
Since it is made from a component file it might be better to define a component file class.
Like this →
This class ties a file, creating it if necessary, and unties it (and destroys it if it was temporary) upon deleting the instance
Oct 2006 OOAPL 147
.Net and other goodies
In addition to the classes which you can write in APL, version 11.0 allows you to work with:
• Dyalog GUI classes, including OLE Servers and and OLE Controls (ActiveX components)
• Microsoft.Net classes
Oct 2006 OOAPL 148
.Net and other goodies
In version 11.0, these classes can be used in exactly the same way as instances of classes which have been implemented in APL.
You create instances of them with NEW, and ⎕you can manipulate the public properties, methods and events which they expose (but unlike APL classes, you cannot see or modify the implementation).
Oct 2006 OOAPL 149
Forms and more via NEW⎕
• It is possible to create forms using new:⎕f1← NEW 'form‘ ((‘caption’ ‘MyForm’)('size' (12 16))⎕
Note that the class name for built-in GUI objects is provided as a string rather than as a reference to a name in the workspace.
• You can create OLE controls with new too:⎕xl← NEW 'OleClient‘ (⎕ ⊂'ClassName‘ 'Excel.Application')
Oct 2006 OOAPL 150
⎕WX
This system function eXposes Window’s interface:
0= do NOT expose anything
+1= expose names and report in NL with ⎕negative argument, use V10 syntax where properties are treated as functions (e.g. Sheet.(Item 3)...)
+2= use new V11 syntax (e.g. Sheet[3]...)
Oct 2006 OOAPL 151
xl← NEW 'OleClient‘ (⎕ ⊂'ClassName‘ 'Excel.Application')
⎕wx allows to use V10 syntax of the new V11 syntax:xl. wx←1 use V10 form⎕ ⍝xl. ActiveWorkbook.Sheets.(Item 1).Namexl. wx←3 use V11 form⎕ ⍝xl.ActiveWorkbook.Sheets[⊂’Sheet2'].Index
⎕WX
Oct 2006 OOAPL 152
.Net and other goodies
Example:standardize dialog
boxesf1← NEW Dialog ('Hello ⎕
World' (50 250) )⍬
Note how the class is based on ‘Form’ (a string) and not Form (a name)
You can do
fm← NEW ‘form’ ...⎕
Oct 2006 OOAPL 153
.Net and other goodies
.Net utilitiesThere is a lot of utilities out there that can be used in APL.For example, the Date/Time utilities found in the .Net DateTime class.They are found in the System namespace.To be able to use the DateTime class you must indicate to APL that it
resides in the System namespace with USING:⎕
⎕USING←’System’now← new DateTime ts⎕ ⎕now let’s see its display form:⍝
2006/10/15 21:47:08⎕nc ‘now’
9
Oct 2006 OOAPL 154
.Net and other goodies
.Net for othersTo allow other languages to use your code you
should organize your classes in namespaces:
WS
NS1
NS2
ClassA ClassB ClassC
ClassX ClassY
Oct 2006 OOAPL 155
.Net and other goodies
.Net for othersTo allow other languages to use your code you• declare how it works
using the :Signaturestatement
• export it through theFile/Export/.Net DLLmenu item
Oct 2006 OOAPL 156
:Signature statement
This statement is used for the outside world where type is important.
It is made up of
:Signature [rt←] fnname [at1 [name1] [,ng2 [,...] ] ]rt← is the return type. If present it MUST be followed by ←
fnname is the name of the function as seen from outside. It does not have to match the function name. This MUST be there.
at1 is the 1st argument type, if present
name1 is the name of the 1st argument as seen from outside. If elided the DLL documentation will skip it and only show the type
,ng2 is the same at/name group for the 2nd argument. If present, the comma MUST be there as it delimits groups
,... same for the other arguments
Oct 2006 OOAPL 157
.Net and other goodies
.Net for othersHere’s how a C# program would use this program:
using System;using APLClasses; // the namespace in which our
classpublic class MainClass { // is found public static void Main() { Primitives apl = new Primitives(); // the APL class int[] rslt = apl.GenIndices(10); // THE call for (int i=0;i<rslt.Length;i++) Console.WriteLine(rslt[i]);} }
Oct 2006 OOAPL 158
.Net and other goodies
.Net for othersHere’s how another APL program would use this
program:
⎕using←'APLclasses,c:\...\apl.dll'
pr← NEW Primitives⎕ pr.GenIndices 10
1 2 3 4 5 6 7 8 9 10
Oct 2006 OOAPL 159
.Net and other goodies
Web services can be written
using APLScript, the scripting version of Dyalog APL, where logic is separated from page layout
• in ASMX files and ASPX files
or
• in workspaces “behind”
Oct 2006 OOAPL 163
:Using
:Using vs USING⎕
:Using X is akin to USING,←X⎕It appends X to USING except when no ⎕
argument is supplied where it means “←0 ”⍴⊂⍬
In a script/class it is necessary to determine the base class/interfaces
Oct 2006 OOAPL 164
Namespaces in script form
)ed ⍟name will edit a new name using the same source format as classes and interfaces.
The source can then be retrieved using SRC and ⎕fixed using FIX.⎕
Namespaces can have a source
Oct 2006 OOAPL 165
Overloading
• Primitives cannot be overloaded by APL classes but some .Net classes are.
• Ex: DateTime objects can be compared using =, >, etc. sorted using ‘grade up’ or added to TimeSpans using +.⎕using←'System'
d1← new DateTime ts⎕ ⎕ d2← new DateTime (2006 10 16)⎕ t1← new TimeSpan (7 2 0 0) 7 days, 2 hours⎕ ⍝ +d3←d1-t12006/10/03 17:12:01 d1<d2,d31 0
Oct 2006 OOAPL 166
There are many advantages to using OO languages over procedural languages:
• ease of modification
• reduced maintenance costs
• easier to model
• can speed up development time
• etc.
Conclusion
Oct 2006 OOAPL 167
OO languages make abstraction easy
They encourage architectures with elaborate layers.
They can be good when the problem domain is truly complex and demands a lot of abstraction.
Conclusion
Oct 2006 OOAPL 168
• All OO languages show some tendency to suck programmers into the trap of excessive layering
• Object frameworks and object browsers are not a substitute for good design or documentation
Careful!
Oct 2006 OOAPL 169
• Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing.
• The Rules of Simplicity, Clarity, and Transparency can get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems.
Careful!