Object Oriented Programming in APL

170
Object Oriented Programming in APL A New Sense of Direction (Oh, Oh!) Dan Baronet 2006 V1.01

description

Object Oriented Programming in APL. A New Sense of Direction (Oh, Oh!) Dan Baronet 2006 V1.01. Introduction. Interoperability & 64 bit OS New WS management New primitives & enhancements to others Object Orientation. V11 has been released. Here are the major features:. - PowerPoint PPT Presentation

Transcript of Object Oriented Programming in APL

Object Oriented Programming in APL

A New Sense of Direction(Oh, Oh!)

Dan Baronet2006V1.01

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 14

The Object Oriented paradigm

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 47

End of OO basics

QUESTIONS

?

Oct 2006 OOAPL 48

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 79

End of implementation

QUESTIONS

?

Oct 2006 OOAPL 80

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 139

End of implementation details

QUESTIONS

?

Oct 2006 OOAPL 140

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 146

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 160

.Net and other goodies

Example of Web services written in APLScript

Oct 2006 OOAPL 161

.Net and other goodies

Example of Web services written in APLScript

Oct 2006 OOAPL 162

.Net and other goodies

With ASPX files:

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!

Oct 2006 OOAPL 170

Buyer beware!

Careful!