COPE 0.04_0

COPE is a CORBA implemented in Perl.

This documents describes the steps you take when writing a CORBA application in Perl using COPE.

First the basics: the laguage binding used.

Scalar types

char

The char type is represented as a 1-character perl string, like a.

octet

octet is represented as a perl number, like 200. We could equally well make octet be exactly the same as char.

Integer types

long and short are no problem. unsigned long might internally be stored as a double, but that should be invisible.

Floating-Point types

Perl has those as well.

Structures

Structures are represented as blessed hashreferences. They inherit from CORBA::_Struct which implements a generic constructor called new, taking key,value pairs.

An example:
# struct MyStruct { // IDL
# boolean simple;
# sequence < octet > list;
# }
package MyStruct;
@ISA=qw(CORBA::_Struct);

my $structvar = new MyStruct( simple => 1, list => [0,1,2] );

Every structure also has a TypeCode defined called _tc (in the appropriate package). In the example case, the typecode would be called $MyStruct::_tc

Sequences

A sequence is represented as an unblessed array reference, with one exception:

octet sequences are represented as a perl string, because they tend to be used for blob-like data.

Arrays

Are also represented as unblessed array references, also with one exception: char arrays, which are again perl strings.

What do people think of these exceptions to the rules?

Enumerations

Are subs with an empty prototype, declared in the appropriate package.

Strings

Are plain scalars.

Unions

I havent looked at them yet (havent needed them either)

Objects

Are Perl objects (blessed references)

TypeCodes

Are Perl objects

Interfaces

Are Perl classes. This means a package and an @ISA array.

Operations

Are Perl methods

Any

Will be a Perl object.

Exceptions

Are Perl classes inheriting from Experimental::Exception

Attributes

I now favour the choice the Java people have made: a method taking zero or one extra arguments, for getting or setting the attribute. This looks the most readable to me.

Parameter passing

in

All types are already scalar in nature, so can be passed as-is. The number of arguments to a method are always exactly as in the IDL.

inout

All non-reference types (numbers and strings) need to be fitted with a and cant be literals.

out

Same as for inout. note: You need to supply an empty anonymous array or hash for sequences, structs or arrays.

Objects need a scalar reference.

Working with TypeCodes

The TypeCodes for basic types are predefined and have names like $CORBA::_tc_boolean All non-basic types have their TypeCode stored in $package::_tc Custom TypeCodes can be built using functions like _create_struct_tc()

Server side

When implementing a server, we need three logically seperate classes:

The implementation of your object

This could be an existing class which you decide to give a shiny new CORBA
wrapper

A generated Skeleton class

This is what gets called by the ORB. It is responsible for decoding method arguments and calling the method

A mapping class

The Mapping class provides the mapping between known method names the skeleton class uses and the possibly unknown names in your implementation class