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.
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 this will be called a 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 it can be 'fully qualified' to make resolution clear.
It is normal in most programming languages to create block scope in functions or member functions (methods on classes). 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 the use of variables in a closure will be explicit.
For classes the scope contains the member variables and member functions (methods). As discussed in the previous post; 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 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 can also facilitate polymorphism. These are the main reasons why C morphed from just structs and functions into C++ an Object Oriented language.
Are operators 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 can also enable the compiler to make a number of assumptions when parsing code (especially when defining 'Generics').
Reuse, Inheritance and Delegation
With both classes and traits we can use the traditional inheritance mechanism provided in most Object Oriented languages. In general this feature is overused. In EK9 we will facilitate a mechanism to make delegation just as easy as inheritance. This will be accomplished through the use of member variables and traits.
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 as easy as inheritance.
Why bother with functions?
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.
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 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 and how higher levels of abstraction for modern concepts should be built into the language from the outset.