# An Object Oriented or a Functional Language

## Background
In my [previous post](https://blog.ek9.io/strong-typing-in-programming-languages) I came to the conclusion that **strong typing** should be adopted in [EK9](https://www.ek9.io).

The next question (before deciding on the **types**) is to consider the pros-and-cons of Object Oriented programming and Functional programming.

## Name Spaces, Scopes and Polymorphism
It is necessary to decide 'where' to locate code when defining an aggregate (structured data) or a function/subroutine. This can assist *Polymorphism* and has an impact on *Coupling*/*Cohesion*.

Some programming languages only have a single global name space in which to define artefacts. This can cause a number of issues, mainly to do with name collisions but also encapsulation of data and function accessibility.

### Name Spaces
Languages such as C++, Java and C# have the concept of a 'namespace' or a 'package' from which artefacts can be *addressed*. This means that it is possible to reduce the collisions of naming. In [EK9](https://www.ek9.io) this will be called a
[**module**](https://www.ek9.io/structure.html#module).
This will allow naming as follows:
```
postalAddress <- general.postal::Address()
networkAddress <- org.network::Address()
```
This allows the name *Address* to be reused, but when this clashes with *Address* from another [**module**](https://www.ek9.io/structure.html#module) it can be 'fully qualified' to make resolution clear.

### Scopes
It is normal in most programming languages to create **block scope** in *functions* or
*member functions* ([*methods*](https://www.ek9.io/methods.html) on
[*classes*](https://www.ek9.io/classes.html)).
This enables variables to be declared within that block, these variables are typically destroyed/lost when the block scope is complete. There are times when it is desirable to let such variables 'live on' such an idea leads to a *closure*.

Some languages allow all variables in a scope to be 'closed over'. In [EK9](https://www.ek9.io) the use of variables in a *closure* will be explicit.

Both [*classes*](https://www.ek9.io/classes.html) and [*functions*](https://www.ek9.io/functions.html) also have their own *scopes*. For *functions* this *scope* acts much like a **block scope**.

For [*classes*](https://www.ek9.io/classes.html) the scope contains the member variables and member functions ([*methods*](https://www.ek9.io/methods.html)). As discussed  in the [previous post](https://blog.ek9.io/strong-typing-in-programming-languages); polymorphism is highly desirable. While it can be implemented in a number of different ways; use of *classes* is one of the most natural.

But [*classes*](https://www.ek9.io/classes.html) are just one aspect of polymorphism that need to be considered; the concept of a set of *method* signatures acting as some type of *interface* or [*trait*](https://www.ek9.io/traits.html) can also facilitate polymorphism. These are the main reasons why C morphed from just *structs* and *functions* into C++ an Object Oriented language.

### [Operators](https://www.ek9.io/operators.html)
If we were not to provide [*classes*](https://www.ek9.io/classes.html)/[*traits*](https://www.ek9.io/traits.html) then we'd have to face the issue of whether or not to include [*operators*](https://www.ek9.io/operators.html) and *operator overloading* with developer defined aggregates (data structures).

Are [*operators*](https://www.ek9.io/operators.html) desirable? Many languages do include this capability such as C++ and C#; others like Java do not. There are significant benefits in providing this capability; the main one being **semantics**.

A defined set of [*operators*](https://www.ek9.io/operators.html) can also enable the compiler to make a number of assumptions when parsing code (especially when defining 'Generics').

So [*operators*](https://www.ek9.io/operators.html) will be included in [EK9](https://www.ek9.io) and they will be defined in the *scope* and context of aggregates (such as [*classes*](https://www.ek9.io/classes.html) and [*traits*](https://www.ek9.io/traits.html)).

### Reuse, [Inheritance](https://www.ek9.io/inheritance.html) and Delegation
With both *classes* and *traits* we can use the traditional [*inheritance*](https://www.ek9.io/inheritance.html) mechanism provided in most Object Oriented languages. In general this feature is overused. In
[EK9](https://www.ek9.io) we will facilitate a mechanism to make [*delegation*](https://www.ek9.io/composition.html) just as easy as [*inheritance*](https://www.ek9.io/inheritance.html). This will be accomplished through the use of member variables and [*traits*](https://www.ek9.io/traits.html).

*Delegation*/Composition encapsulates data better, facilitates reuse, enables cohesion and makes coupling more flexible. It is currently under used because few programming languages have built in syntax to make [*delegation*/composition](https://www.ek9.io/composition.html) as easy as [*inheritance*](https://www.ek9.io/inheritance.html).

## Why bother with functions?
Are [*functions*](https://www.ek9.io/functions.html)  necessary then? *Functions* provide a small, stateless and succinct artefact for processing steps. Moreover they are easily reusable and can be made ['pure'](https://www.ek9.io/basics.html#pure) (i.e. having no side effects).

In conjunction with the [*delegation*](https://www.ek9.io/composition.html) model outlined for [*classes*](https://www.ek9.io/classes.html) and [*traits*](https://www.ek9.io/traits.html); [*functions*](https://www.ek9.io/functions.html) can also be reused via delegation. 

But most importantly there are elements of functionality that do not have a natural 'home' as part of a  [*classes*](https://www.ek9.io/classes.html); they stand in there own right within the context of a [**module**](https://www.ek9.io/structure.html#module).

This is particularly important when the subject of 'streaming pipelines' is addressed. Many languages use/reuse *methods* on *classes* to implement what is called a 'fluent' programming interface.

But [EK9](https://www.ek9.io) will follow the Unix philosophy and use distinct syntax with the pipe **|** symbol for [stream pipelines](https://www.ek9.io/streamsAndPipelines.html).

 [EK9](https://www.ek9.io) will also introduce the concept of an [*abstract function*](https://www.ek9.io/dynamicFunctions.html) in a similar manner to the **C typedef** in the previous article.

## Conclusion
*Functions*, *Classes* and *Traits* are all required in EK9. They each bring capability and reuse but in different but complementary ways and can be used in combination.

So [EK9](https://www.ek9.io) will provide syntax and semantics for both Object Oriented Programming and Functional Programming.

The next blog post will cover the basic **types** that will be provided by [EK9](https://www.ek9.io) and how higher levels of abstraction for modern concepts should be built into the language from the outset.