[ANN] funKTionale 0.2.1

The next version of funKTionale is ready

The changes are

The Option and Either types are defined with basic functionality, upcoming funKTionale versions will add more features to this types (Some other languages like Haskell or libraries like scalaz for Scala, have more rich featured types or more specialized ones)

This is cool although I still haven't found a way to apply functional style programming in my Kotlin project. Maybe I am too addicted to imperative programming.

We are all embracing some functional styles in our imperative code. Sometimes we just do not notice it. Consider a user-defined List class:

class List<T> {
  // …
  fun contains(t: T): Boolean { … }

and a typical usage:

val xs: List<Int> = …
if(xs.contains(5)) …

Function literals make the member function contains more useful:

class List<T> {   // ...   fun contains(t: T): Boolean { ... }   fun contains(predicate: (T) -> Boolean): Boolean { ... } }

Now the definition expects a function that seeks a match. The usage is now:

val xs: List<Int> = …
if(xs.contains({t -> (t == 5)})) …

But the definition now lets us ask other questions of the List:

if(xs.contains({t -> (t < 0)})) …           // any negative value?
if(xs.contains({t -> (t % 2 == 0)})) …   // any even-valued value?

The member function contains is now an example of a higher-order function - one that
accepts a function parameter. Other higher-order functions return function values. Its a
short step from there to using curried functions, partial function application, functions as
class properties, and on to an ever increasing usage of a functional style in an imperative

Well I think merely using high order functions in collections is hardly programming in functional way.

Its a short step from there to using curried functions…”

This short step seems to me pretty long … I mean using named/default arguments is damn convenient  instead of partial applications for example.

Thanks for your kind comments.

In fact the transition from imperative to functional is cumbersome, but the big advantage of this OOP with functional features languages (Scala, Kotlin) is that let you program in the style that you want and adopt other style at your own pace

I don’t use every functional feature in my own projects only the features that make sense in the project context

“black cat, white cat, what does it matter so long as it catches the mice”