object oriented programming in apl
Download
Skip this Video
Download Presentation
Object Oriented Programming in APL

Loading in 2 Seconds...

play fullscreen
1 / 170

Object Oriented Programming in APL - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Object Oriented Programming in APL' - lacey-blackburn


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

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

slide48

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

slide80

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:

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

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 NS 9.1
  • Forms 9.2
  • Instances 9.2 (NOT 9.3!)
  • Classes 9.4
  • Interfaces 9.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

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

slide146

.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

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

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

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

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

ad