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

Object Oriented Programming in APL PowerPoint PPT Presentation


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

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:

OOAPL


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

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?

  • 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

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

OOAPL


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

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

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 data

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

d

a

t

a

code

OOAPL


The evolution of data

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

OOAPL


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


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

Definitions

OOAPL


OO fundamental concepts

The Object Oriented paradigm is based on:

  • Classes

  • Instances

  • Members

  • Message passing

  • Inheritance

  • Encapsulation

  • Polymorphism

OOAPL


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

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

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

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

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

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

QUESTIONS

?

OOAPL


The

Dyalog APL

way

OOAPL


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


Implementation

Let’s see how Dyalog APL does this:

  • Classes

  • Instances

  • Members

  • Message passing

  • Inheritance

  • Encapsulation

  • Polymorphism

OOAPL


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

In the workspace MyClass appears as a namespace:

⎕NC ‘MyClass’

9

)CLASSES

MyClass

OOAPL


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

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

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

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

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

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


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

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


Implementation: inheritance

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


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

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

  • 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

QUESTIONS

?

OOAPL


Implementation

Details

OOAPL


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

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

pet←⎕NEW Collie ‘Rex’

pet.⎕nl -2

Name Nlegs Sounds Type

pet.(Name Type)

Rex canis familiaris

OOAPL


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

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

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

⎕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/⎕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/⎕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/⎕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/⎕NL

⎕NC/⎕NL extensions

⎕NL also reports instance members when used with a negative argument

instance.⎕NL -2.1⍝ report all fields

OOAPL


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

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

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

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

Outside world (e.g. WS)

abc

I am ABC

abc.⎕NL 2 3

∇f1

...

f1

v11

v11←’var’

OOAPL


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

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

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

All namespaces have a common structure

  • They inherit system variables

  • The system variables exist both internally AND externally

OOAPL


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

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

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

Outside world (e.g. WS)

)ed ∘ maneuvering

⍴maneuvering.⎕NC -2 3

0

maneuvering.v11←12

maneuvering.⎕NC -2 3

v11

OOAPL


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

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

  • 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

QUESTIONS

?

OOAPL


Examples

OOAPL


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 Class

This class also has

  • 5 shared functions

    These perform the basic operations: + × ÷ *

OOAPL


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

The idea is to have a file whose components are accessed by key instead of a number.

Sort of

file.Read ‘key’

OOAPL


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


.Net and other

goodies

OOAPL


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

  • 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


⎕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


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

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

Example of Web services written in APLScript

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

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

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

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

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

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

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





OOAPL


.Net and other goodies

Example of Web services written in APLScript

OOAPL


.Net and other goodies

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

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

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

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

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









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

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

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

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

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









With ASPX files:

OOAPL


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

  • 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

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


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!

  • 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


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


Careful!

Buyer beware!

OOAPL


  • Login