Welcome to the wiki for Object-Centred Euphoria (OCE).

This wiki outlines the (abstracted) concept of Object-Centred Programming (OCP). Some details are given of the specific implementation of OCE which applies to the Euphoria Programming Language and is the subject of this repository.

What is an Object?

An Object is essentially any specified kind of data structure.

Instances of Objects are created by declaration. This declaration includes a statement of the Object's (potential) properties. Those properties are part of the process of defining each Object. Instances can be assigned values, either alongside a declaration or at any subsequent point in a coding block where the Instance still exists. Any such values must conform to the defining properties of the associated Object.

Defining new Objects

Every type of Object must be defined via a unique process. Further Objects are defined by declaring a new process by an analogous means.

In Open Euphoria (OE) the defining process is known as typing and is delivered by the keyword type. A type definition looks just like a function definition except that all return values are boolean. Every new type defined is achieved by refining the definition of a pre-existing type.

Unlike inheritance in OOP, typing restricts a definition: to the present type and all sub-categories of that parent Object type.

How are Objects manipulated

An Instance variable can be re-assigned another (conforming) value. Such a re-assignment can be achieved either by

• applying some form of operator (mathematical, logical, linguistic) to the Instance
• applying a valid routine (cf an OOP method) to the Instance
• assigning a new value to the Instance, this value conforming to the Object's Type definition

Note that routines specified to operate on a child Object Type, only work at the child level (or grand-child, etc) and are invalid if applied to an Instance of the parent.

How is OCP realised?

Firstly an implementation must consist of core Objects and provide the ability to define child Objects with known parentage.

Secondly an implementation must be able to define Instances and assign values to them, accompanied by the capacity to test the validity (in Object terms) of that assignment - in other words, be able to test that the value is valid for that type of Object.

An implementation must also have the capacity to define routines which restrict their operation to a specified type of Object.

OCP in action

To my knowledge no existing programming language delivers OCP "out of the box", although the hybrid language Python comes close, as does Lua. Consequently, I have decided to realise OCP by developing my own project, code-named OCE, standing for Object-Centred Euphoria. The implementation uses (and thus requires) at least Version 4.0.5 of the language (the standard release) but has been built using the latest (beta) version of 4.1.0, which comes in both 32-bit and 64-bit versions. The language offers a lot of the necessary tools for realising OCP, as well as the capacity to re-define itself in a number of useful ways. What's more it is pretty easy to learn (one of the best, in my view).

What is OCE?

Euphoria is a file-based interpreted language, so OCE, too, requires a source file to exist before interpretation or execution is possible. It is based on a core set of Object types, all built into the interpreter, and offers a small set of library modules to deliver the Object-specific functionality. (OE4 does offer a form of compilation, but I will not go down that road at present.)

Euphoria consists of a language core, delivered through the interpreter (invoked by eui[w].exe), and, in the normal distribution, a set of add-on "standard" libraries, which replace or build upon, the original set of "includes" of the original language. OCE parallels that approach insofar as it builds solely from the core and offers (hopefully more logical) alternatives to those standard libraries, which play no part in OCE.

OCE utilises Euphoria's core Object (object) and incorporates the other built-in types (atom, integer and sequence). In OCE (as in OE4) new types are defined by using the quasi-routine type to confirm the Object definition. The basis of type is that it takes a single argument, the importance of which is the type and not the argument name.

Two types of Instances are recognised in OCE: fixed (constant) and variable. Instance type-checking is built into OE4 (and hence OCE) for variables: every time a value is assigned to an Instance the type is checked, prior to assignment. Type-checking of fixed values, however, can only be done if the assignment is made using a creator function, which, following OOP convention, I shall call a Constructor.

OE4 offers two types of routine: the procedure and the function. The former has no return value, but the latter does. There is, however, no requirement that it be trapped, so the long-term objective is to rely only on the function. The current implementation of OCE, however, because it relies quite a lot on re-defining existing OE4 code, uses procedure in all cases where the return value would be void. Every routine is limited, in its definition, to at least one Object Type and OCE will invoke, at run time, a type-checking error if it is used out of context.

OE4 also offers the facility of setting default values for arguments. This facility is well used within OCE to create the equivalent of overloading. Indeed one of the guiding principles of OCE, as distinct from OE, is to define as small a number of routines as possible.

OCE, as delivered here, consists of just three library modules. The files atom.e and sequence.e contain within each the set of Object Types and associated routines derived, respectively, from the atom and sequence types. The third module object.e "sits on top" of these two and provides additional functionality where types and/or routines need access to both single-valued and multi-valued Objects.

For convenience OE4's standard file-type conventions are adopted in OCE:

• .e for library modules
• .ew for GUI-based library modules
• .ex for terminal-based applications
• .exw for GUI-based applications

The long-term goal of OCE is to handle two forms of coding:

• a procedural type of syntax, of the form <routine>(<instance>[, parameter_values])
• a dot notation syntax, of the form <instance>.<routine>([parameter_values])

Initial work concentrates on the first of these forms, both in the module specification and the demonstration examples. The next stage will be to introduce the dot notation syntax into the examples only; the final stage will (hopefully) enable module specification and application code to be all of the former style.

Libraries

The OCE libraries are filed in the include folder. All OCE applications must incorporate a call to include object.e.

Documentation

All the OCE library modules and all the illustrative examples provided have the documentation embedded inside the code module, using a Creole-based system. Although the extraction program has been applied to generate the documentation files (html files held in the docs folder), reading through the library source code with the embedded documentation should give the reader a lot of useful information about the inner workings of OCE.

Examples

The demos folder includes examples of OCE in action. In the main the demos are quite short and are designed to test the functionality of specific OCE modules. So, for example, a demo entitled string.ex tests the functionality of the string type stored in library module sequence.e.

Eventually more detailed and elaborate examples will be added as more type definitions come on stream and more functionality is required of those types already defined.

Conclusion

I hope you have lots of fun exploring OCE!

I also hope that you find value and utility in the Object-Centred concept.