Design note: small type APIs, functions and pipelines
This note goes with EK9 Built in Types, where the position comes up in the String, Bits and DateTime sections. If you have ever thought "why is there no method on this class to do X?", this is the answer.
No static methods
EK9 has no static methods attached to classes. Two mechanisms do that job instead:
- functions that return an object in a particular state, and
- methods that do not alter the object they are called on but return a value.
This can seem strange at first, but it removes the fixed, binding nature of a static method on one class, and to some degree it removes the need for Factory classes.
Few methods on a type
Most object-oriented languages keep adding methods to their types, for substrings and the like. EK9 puts the very frequent operations on the type (converting to upper or lower case, say). For the less frequent ones it gives you the tools, functions and pipelines, to write your own, and you build them up as your own library.
That keeps the EK9 standard library small. It will grow over time, but in a controlled way.
Pipelines instead of special methods
Selecting part of a String or of some Bits with a pipeline (skip, head, tail, map) is the same every time, whatever the type. Given a page, the same approach filters and selects paragraphs by whatever criteria you need. Rather than a set of object-specific methods on each class for each kind of sub-selection, the functional approach is repeatable and consistent.
This is not aimed at denigrating object orientation. It splits development between object orientation and functional programming, each where it fits. You may find it difficult at first. When you catch yourself thinking "why is there no method on this class to do X?", consider a more functional approach. Over time your classes become smaller and more concise, and your library of functions grows and is reusable in many more contexts.
It is accepted that a pipeline is not as terse as a list comprehension. In exchange it is one general syntax: the processing, accumulation, mapping and teeing are the same for Integer, Duration or your own types.
Operators, not method names
Date, Time, DateTime, Duration and Money use the ordinary mathematical operators, each overloaded only with the types where it makes sense (a Duration times an Integer, a Date plus a Duration). Your own records and classes can do the same. Keeping the same semantics whatever the type reduces the surface area of method names and ideas, and the number of classes. So although EK9 has many types, constructs and operators, it needs fewer method names, helper classes and third-party APIs.
Go with the grain
If you adopt EK9, go with the grain and flow of it. If you find yourself fighting it, a different language such as C or C# would serve you better.