Object oriented programming in apl
This presentation is the property of its rightful owner.
Sponsored Links
1 / 170

Object Oriented Programming in APL PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on
  • Presentation posted in: General

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:.

Download Presentation

Object Oriented Programming in APL

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Object oriented programming in apl

Object Oriented Programming in APL

A New Sense of Direction

(Oh, Oh!)

Dan Baronet

2006

V1.01


Introduction

Introduction

  • Interoperability & 64 bit OS

  • New WS management

  • New primitives & enhancements to others

  • Object Orientation

V11 has been released.

Here are the major features:

OOAPL


This talk is based on 2 things

This talk is based on 2 things:

  • Why? Why should I know about this? Why am I here?

  • OK, I’m still here, how do I use it?

OOAPL


Synopsis

Synopsis

Why should I be here?

  • Reasons

    How do I use this?

  • History of OO

  • Definitions

  • The APL way

  • Implementation details

    Real Life Example (SJT)

OOAPL


Reasons why do this

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

OOAPL


Net was already in v10

.Net was already in V10

The ability to use .Net with classes was already there in V10 but it was more difficult to use.

OOAPL


History

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

OOAPL


The evolution of data

The evolution of data

  • Elementary data elements (like int) and arrays of them (all the same)

  • Structures (like {i: int; d: date}), many elementary elements or structures (recurs)

  • Namespaces (structures whose elements are referred to by name)

  • Classes (namespaces with initializers & cleaners)

OOAPL


Data in dyalog apl dyw

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.

OOAPL


The evolution of data1

The evolution of data

In traditional (procedural) systems, data is separated from code:

d

a

t

a

code

OOAPL


The evolution of data2

The evolution of data

This is the same in traditional APL systems, data is separated from code:

OOAPL


The evolution of data3

private

code

private

code

d

a

t

a

d

a

t

a

The evolution of data

In OO systems, data is more tightly coupled with code:

Do this

Do that

OOAPL


The evolution of data4

private

code

private

code

d

a

t

a

d

a

t

a

The evolution of data

In OO APL systems, data is also tightly coupled with code but in a more procedural manner:

OOAPL


The object oriented paradigm

The Object Oriented paradigm

Definitions

OOAPL


Oo fundamental concepts

OO fundamental concepts

The Object Oriented paradigm is based on:

  • Classes

  • Instances

  • Members

  • Message passing

  • Inheritance

  • Encapsulation

  • Polymorphism

OOAPL


Oo fundamental concepts1

OO fundamental concepts

1. Classes

A 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.

OOAPL


Oo fundamental concepts2

OO fundamental concepts

Classes

A classcan 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.

OOAPL


Interfaces example

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.

OOAPL


Interfaces example1

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);

...

OOAPL


Interfaces example2

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);

...

OOAPL


Oo fundamental concepts3

OO fundamental concepts

2. Instances

Those 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.

OOAPL


Oo fundamental concepts4

OO fundamental concepts

3. Members

This 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.

OOAPL


Oo fundamental concepts5

OO fundamental concepts

Members: Methods

Those 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.

OOAPL


Oo fundamental concepts6

OO fundamental concepts

Members: Fields

Those can either reside in the class (shared field) or in the instance (instance field).

They can also be read only.

OOAPL


Oo fundamental concepts7

OO fundamental concepts

Members: Properties

Those are Fieldsimplemented 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).

OOAPL


Oo fundamental concepts8

OO fundamental concepts

4. Message passing

This 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.

OOAPL


Oo fundamental concepts9

OO fundamental concepts

5. Inheritance

This 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.

OOAPL


Oo fundamental concepts10

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)

OOAPL


Oo fundamental concepts11

OO fundamental concepts

Inheritance: Based classes (reusability)

A class can be based on another based class. See classCollie based on Dog based on Animal

Big Dane: Dog

Instances

Dog: Animal

Fido (Collie)

Animal

Classes

Collie: Dog

Fish: Animal

Rex (Collie)

OOAPL


Oo fundamental concepts12

OO fundamental concepts

Inheritance

When 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.

OOAPL


Oo fundamental concepts13

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

Mule

Donkey

OOAPL


Override concept

Override concept

Class B

Class A

M1

M2

M1

M2

M2

‘I am B’

M2

‘I am A’

// M1 calls its own M2:

(NEW B).M1

I am B

// M1 calls its own M2:

(NEW A).M1

I am A

OOAPL


Based classes

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2

M2

‘I am A’

M2

‘I am B’

// M1 calls its own M2:

(NEW B).M1

I am A

// M1 calls its own M2:

(NEW A).M1

I am A

OOAPL


Based classes1

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2

M2: Override

‘I am B’

M2

‘I am A’

// M1 calls its own M2:

(NEW B).M1

I am A

// M1 calls its own M2:

(NEW A).M1

I am A

A:M2 does not allow to be overriden

OOAPL


Based classes2

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2:

Overridable

M2: Override

‘I am B’

M2

‘I am A’

// M1 calls its own M2:

(NEW B).M1

I am B

// M1 calls its own M2:

(NEW A).M1

I am A

A:M2 does allow to be overriden AND B wants to override it

OOAPL


Oo fundamental concepts14

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).

OOAPL


Example a car

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.

OOAPL


Encapsulation

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.

OOAPL


Oo fundamental concepts15

OO fundamental concepts

Encapsulation: private

A 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 only

seen in the

pale area

sub1

sub2

OOAPL


Oo fundamental concepts16

OO fundamental concepts

Encapsulation: protected

A protected member can only be seen from within the instance of from within instances within it.

M is only

seen in the

pale area

sub1

sub2

OOAPL


Oo fundamental concepts17

OO fundamental concepts

Encapsulation: public

A public member can be seen from anywhere. All Methods can access it from anywhere whether it is public shared or public instance.

M is seen

in all the

pale area

sub1

sub2

OOAPL


Oo fundamental concepts18

OO fundamental concepts

Encapsulation: friend

A class declared friend can see the offerer’s private and public members.

Class B

Class A

Private Av

Public Au

Private Pv

Public Pu

Friend A

Here A sees B’s members

as its own members

OOAPL


Oo fundamental concepts19

OO fundamental concepts

7. Polymorphism

It 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)

OOAPL


Oo fundamental concepts20

OO fundamental concepts

Polymorphism example

Foo (integer arg)

{

// fn called with

// an integer arg

Print “Int arg”

}

Foo (string arg)

{

// fn called with

// a string arg

Print “String arg”

}

Same function name, different code

OOAPL


Oo fundamental concepts21

OO fundamental concepts

Polymorphism

A program that accepts multiple definitions

is said to be overloaded.

Sometimes arguments have to be coerced

into a new type to achieve proper behaviour.

OOAPL


Oo c oncepts summary

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

OOAPL


End of oo basics

End of OO basics

QUESTIONS

?

OOAPL


Object oriented programming in apl

The

Dyalog APL

way

OOAPL


Implementation

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

OOAPL


Implementation1

Implementation

Let’s see how Dyalog APL does this:

  • Classes

  • Instances

  • Members

  • Message passing

  • Inheritance

  • Encapsulation

  • Polymorphism

OOAPL


Implementation classes

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. #)

OOAPL


Implementation classes1

Implementation: classes

In the workspace MyClass appears as a namespace:

⎕NC ‘MyClass’

9

)CLASSES

MyClass

OOAPL


Implementation members

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)

OOAPL


Implementation members1

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.

OOAPL


Implementation members2

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.

OOAPL


Implementation members3

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

OOAPL


Implementation instances

Implementation: instances

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

OOAPL


Implementation new

Implementation: ⎕NEW

⎕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.

OOAPL


Implementation new1

Implementation: ⎕NEW

Example:

myInstance←⎕NEW MyClass

The display form includes [brackets] by default

myInstance

#.[MyClass]

It is another type of namespace

⎕NC ‘myInstance’

9

OOAPL


Implementation constructors

Implementation: constructors

Classes may require something to initialize the instance. Ex:

)ED ○ Animal

  • Here an animal must

  • be have at least two

  • characteristics:

  • # of legs

  • the sounds it makes

OOAPL


Implementation constructors1

Implementation: constructors

Several instances can be made up of the same Animal class:

After running

this function

we have:

)obs

fish 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

OOAPL


Implementation message passing

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

OOAPL


Implementation inheritance

Implementation: inheritance

Inheritance: Based classes

A class can be based on another based class. See classCollie based on Dog based on Animal

Big Dane: Dog

Instances

Dog: Animal

Fido (Collie)

Animal

Classes

Collie: Dog

Fish: Animal

Rex (Collie)

OOAPL


Implementation inheritance1

Implementation: inheritance

Example: a bird’s generic description is ‘plain Bird’

Birdy←⎕NEW Bird

Birdy.Desc

plain Bird

Bird

Birdy (Bird)

When Birdy is created, Bird’s constructor is called

OOAPL


Implementation inheritance2

Birdy (Bird)

Bird

Parrot: Bird

Coco (Parrot)

Implementation: inheritance

Example: a parrot is a bird

Coco←⎕NEW Parrot

Coco.Desc

Not a plain Bird, a Parrot

OOAPL


Implementation inheritance3

Implementation: inheritance

We can create classes and instances at all levels

Birdy (Bird)

Bird

Coco (Parrot)

Classes

Instances

Parrot: Bird

Tweety (Macaw)

Macaw: Parrot

OOAPL


Implementation inheritance4

Implementation: inheritance

Inheritance: constructors with arguments

Using the animal kingdom as example.

Big Dane: Dog

Instances

Dog: Animal

Fido (Collie)

Animal

Classes

Collie: Dog

Fish: Animal

Rex (Collie)

OOAPL


Implementation inheritance5

Implementation: inheritance

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


Implementation inheritance6

Implementation: inheritance

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


Implementation encapsulation

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.

OOAPL


Implementation encapsulation1

Implementation: Encapsulation

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:

:Fieldpublic MyField

OOAPL


Implementation encapsulation2

Implementation: Encapsulation

The class to the right shows a few fields (vars) and their access.

The access is the same for methods (fns) and properties.

OOAPL


Implementation encapsulation3

Implementation: Encapsulation

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)

OOAPL


Implementation encapsulation4

Implementation: Encapsulation

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.

OOAPL


Implementation encapsulation5

Implementation: Encapsulation

Shared vs instance

in1←⎕new keepCount

I am XYZ1

in2←⎕new keepCount

I am XYZ2

in3←⎕new keepCount

I am XYZ3

keepCount.Count

3

keepCount.⎕nl-2

Count

in2.⎕nl-2

Count MyName

in1.Count

3

OOAPL


Implementation polymorphism

Implementation: Polymorphism

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.

OOAPL


Implementation polymorphism1

Implementation: Polymorphism

: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

Example:

Depending on the number of arguments, the proper fn will be used.

OOAPL


Implementation summary

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

OOAPL


End of implementation

End of implementation

QUESTIONS

?

OOAPL


Object oriented programming in apl

Implementation

Details

OOAPL


Implementation details

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.

OOAPL


Implementation details1

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.

OOAPL


Implementation details2

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

OOAPL


Implementation details3

Implementation details

Classes:

A classcan implement one or more interfaces.

An interface describes what it should do.

The class describes how it should be done.

OOAPL


Implementation details4

Implementation details

This maneuvering interface describes what has to be done with a machine:

)ed ∘maneuvering

It does NOT specify

how it should be

done.

OOAPL


Implementation details5

Implementation details

This car class implements maneuvering:

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...

OOAPL


Implementation details6

Implementation details

This plane class implements maneuvering:

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

OOAPL


Implementation details7

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

OOAPL


Implementation details8

Implementation details

Properties

In 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.

OOAPL


Implementation details9

Implementation details

Properties: SIMPLE case

When 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).

OOAPL


Implementation details10

Implementation details

Properties: KEYED case

The 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.

OOAPL


Implementation details11

Implementation details

Properties: NUMBERED case

The 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.

OOAPL


Implementation details12

Implementation details

Default Properties

There 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

OOAPL


Triggers

Triggers

Implementation details

t←⎕NEW trigger1 ('Daniel' 'Baronet')

Full name is Daniel Baronet

Full name is Daniel Baronet

t.FirstName←'Dan'

Full name is Dan Baronet

OOAPL


Implementation details13

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

OOAPL


Implementation details base

Implementation details: :Base

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


Implementation details base1

Implementation details: ⎕Base

⎕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

OOAPL


Implementation details14

Implementation details

Override and overridable

These concepts allow a base class code to be overridden.

The following slides will attempt to explain this in more details.

OOAPL


Non based classes

Non-Based classes

⍝ M1 calls its own M2:

(⎕NEW B).M1

I am B

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Non based classes1

Non-Based classes

Class B

Class A

M1

M2

M1

M2

M2

‘I am B’

M2

‘I am A’

⍝ M1 calls its own M2:

(⎕NEW B).M1

I am B

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Based classes3

Based classes

⍝ M1 calls its own M2:

(⎕NEW B).M1

I am A

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Based classes4

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2

M2

‘I am A’

M2

‘I am B’

⍝ M1 calls its own M2:

(⎕NEW B).M1

I am A

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Overridden classes

Overridden classes

⍝ M1 calls its own M2 because

⍝ it has not been overridden:

(⎕NEW B).M1

I am A

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Based classes5

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2

M2

‘I am B’

M2

‘I am A’

⍝ M1 calls its own M2:

(⎕NEW B).M1

I am A

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Overridden classes1

Overridden classes

⍝ M1 calls B’s M2 because

⍝ it has been overridden:

(⎕NEW B).M1

I am B

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Based classes6

Based classes

Class B: A

Class A

There is no M1 in B

so A’s (on which B is based) M1 is used

M1

M2

M2

‘I am B’

M2

‘I am A’

⍝ M1 calls B’s M2:

(⎕NEW B).M1

I am B

⍝ M1 calls its own M2:

(⎕NEW A).M1

I am A

OOAPL


Implementation details15

Implementation details

Destructors

They 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.

OOAPL


Implementation details nc nl

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’

9

To find their sub-class they need to be enclosed:

⎕NC ⊂‘myClass’

9.4

OOAPL


Implementation details nc nl1

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

OOAPL


Implementation details nc nl2

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

OOAPL


Implementation details nc nl3

Implementation details: ⎕NC/⎕NL

⎕NC/⎕NL extensions

⎕NL and ⎕NC also apply to variables and functions.

The complete list is:

23/49

n.1 VariableTraditional fn/opNS created by ⎕NS

n.2 FieldD-fns or –opInstance (could be form)

n.3 PropertyDerived/Primitive -

n.4 --Class

n.5 --Interface

n.6 External/sharedExternal External Class

n.7 --External Interface

OOAPL


Implementation details nc nl4

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

OOAPL


Implementation details16

Implementation details

Types of Namespaces and their ⎕NC

The 1st two already existed in V10

  • Regular NS9.1

  • Forms9.2

  • Instances9.2 (NOT 9.3!)

  • Classes9.4

  • Interfaces9.5

OOAPL


Implementation details df

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)

OOAPL


Display form of namespaces

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

OOAPL


Contents of namespaces

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

OOAPL


Contents of namespaces1

Contents of namespaces

To get a distinct copy of t1.s1 we need to do

abc←⎕NS ⎕OR ‘t1.s1’

,abc.⎕NL 2 3 ⍝ everything is copied

f1 v11

abc ⍝ even its name

(S1: son of t1)

abc≡t1.s1 ⍝ but they’re different

0

abc.⎕fd ‘I am ABC’ ⋄ abc

I am ABC

OOAPL


Contents of namespaces2

Contents of namespaces

Outside world (e.g. WS)

abc

I am ABC

abc.⎕NL 2 3

∇f1

...

f1

v11

v11←’var’

OOAPL


Contents of namespaces3

Contents of namespaces

abc

You can addto a namespace:

tx←{,⍵}

‘abc’ ⎕ns ‘tx’

and <tx> appears

without ‘v11’ or <f1>

going away.

I am ABC

∇f1

...

v11←’var’

∇tx←{,⍵}

OOAPL


Contents of namespaces4

Contents of namespaces

abc

But if you use ← instead:

tx←{,⍵}

abc←⎕ns ‘tx’

<tx> appears in

‘abc’ alone and

the display form is reset

#.[Namespace]

∇tx←{,⍵}

OOAPL


Display form of a form

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>

OOAPL


Display form of a form1

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>

OOAPL


Contents of a form

Contents of a form

The form contains 2 objects:

⍴⎕←⎕nl 2 3 9

b1

e2

2 2

⎕nc ‘b1’

9

⎕nc ‘Caption’

0

<F1 is in great form>

e2

OOAPL


Contents of a form1

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.

OOAPL


Contents of a form2

Contents of a form

The form now contains 4 objects:

⍴⎕←F1.⎕nl 2 3 9

b1

e2

f1

v1

4 2

⎕nc ‘F1.b1’

9

<F1 is in great form>

e2

∇ f1

whatever

v1←’some var’

OOAPL


Contents of a form3

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 membersinside the form. They do NOT appear in ⎕nl +2 3

OOAPL


Contents of a form4

Contents of a form

The form has 2 types of functions and variables:

  • Those internal and specific to its type

  • 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

OOAPL


Contents of namespaces5

Contents of namespaces

All namespaces have a common structure

  • They inherit system variables

  • The system variables exist both internally AND externally

OOAPL


Contents of a form5

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

OOAPL


Contents of a class

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

OOAPL


Contents of a class1

Contents of a class

Outside world (e.g. WS)

ShrIns

Master Share/instance

ShrIns.⎕NL -2 3

FS1 MS1

The private members cannot be seen or accessed from outside.

∇MS1

∇MS0

FS1 (no value)

FS0 (no value)

OOAPL


Contents of a class2

Contents of a class

Outside world (e.g. WS)

ShrIns

You can add items “outside” a class:

tx←{,⍵}

‘ShrIns’ ⎕ns ‘tx’

ShrIns.v11←32

and they appear

without anything else

going away.

Master Share/instance

∇MS1

FS1 (no value)

v11←32

∇tx←{,⍵}

OOAPL


Contents of a class3

Contents of a class

Outside world (e.g. WS)

ShrIns

ShrIns.⎕NC 2 3

tx

v11

ShrIns.⎕nc-2 3

tx v11 FS1 MS1

Master Share/instance

∇MS1

FS1 (no value)

v11←32

∇tx←{,⍵}

OOAPL


Contents of an instance

Contents of an instance

Outside world (e.g. WS)

SI1

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.

#.[ShrIns]

∇MI1

∇MS1

FS1

(no value)

FI1

(no value)

Instance

members

Class

members

OOAPL


Contents of an interface

Contents of an interface

Outside world (e.g. WS)

)ed ∘ maneuvering

⍴maneuvering.⎕NC -2 3

0

maneuvering.v11←12

maneuvering.⎕NC -2 3

v11

OOAPL


Contents of an interface1

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

OOAPL


Include

: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.

OOAPL


Implementation details summary

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

OOAPL


End of implementation details

End of implementation details

QUESTIONS

?

OOAPL


Object oriented programming in apl

Examples

OOAPL


Complex class

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

  • ...

OOAPL


Complex class1

Complex Class

This class also has

  • 5 shared functions

    These perform the basic operations: + × ÷ *

OOAPL


Complex class2

Complex Class

This class also has

  • 2 constructors and

  • 2 private functions

    one of which is a trigger for when one of the fields is modified

OOAPL


Keyed component file

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’

OOAPL


Keyed component file1

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

Keyed component file

OOAPL


Object oriented programming in apl

.Net and other

goodies

OOAPL


Net and other goodies

.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

OOAPL


Net and other goodies1

.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).

OOAPL


Forms and more via new

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')

OOAPL


Object oriented programming in apl

⎕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]...)

OOAPL


Object oriented programming in apl

⎕WX

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).Name

xl.⎕wx←3 ⍝ use V11 form

xl.ActiveWorkbook.Sheets[⊂’Sheet2'].Index

OOAPL


Net and other goodies2

.Net and other goodies

Example:

standardize dialog boxes

f1←⎕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’ ...

OOAPL


Net and other goodies3

.Net and other goodies

.Net utilities

There 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

OOAPL


Net and other goodies4

.Net and other goodies

.Net for others

To allow other languages to use your code you should organize your classes in namespaces:

NS1

ClassA

ClassB

ClassC

WS

ClassX

ClassY

NS2

OOAPL


Net and other goodies5

.Net and other goodies

.Net for others

To allow other languages to use your code you

  • declare how it works using the :Signaturestatement

  • export it through theFile/Export/.Net DLLmenu item

OOAPL


Signature statement

: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.

at1is 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

OOAPL


Net and other goodies6

.Net and other goodies

.Net for others

Here’s how a C# program would use this program:

using System;

using APLClasses; // the namespace in which our class

public 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]);

} }

OOAPL


Net and other goodies7

.Net and other goodies

.Net for others

Here’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

OOAPL


Net and other goodies8

.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”

OOAPL


Net and other goodies9

.Net and other goodies

Example of Web services written in APLScript



x















OOAPL


Net and other goodies10

.Net and other goodies

Example of Web services written in APLScript

OOAPL


Net and other goodies11

.Net and other goodies





































With ASPX files:

OOAPL


Using

: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

OOAPL


Namespaces in script form

Namespaces in script form

Namespaces can have a source

)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.

OOAPL


Overloading

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-t1

    2006/10/03 17:12:01

    d1<d2,d3

    1 0

OOAPL


Conclusion

Conclusion

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.

OOAPL


Conclusion1

Conclusion

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.

OOAPL


Careful

Careful!

  • 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

OOAPL


Careful1

Careful!

  • 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.

OOAPL


Careful2

Careful!

Buyer beware!

OOAPL


  • Login