Either Disjoint Or Union Types

Many languages support union types, and it is high time Scala did. Union types are coming in upcoming version of Scala – Dotty. Union types (|) are already being compared with Either and Option (disjoint unions).

In some ways, Either and Option may be expressed as union types.

// Option[String]
String | null

// Either[Int, String]
Int | String

Similar to disjoint union types, you can pattern match over Union types. However, the differences outshine the similarities.

Disjoint union types like Either and Option …

• constraint the universe of types to be unique – Left and Right, Some and None. There is only one Left or Some.
• can be parameterized – Either[L, R] , Option[T]
• Defined in the standard library. Not language syntax.

On the other hand, Union Types (|) …

• Not parameterized. Types are specific.

• The types involved don’t have to be necessarily unique.

  String | Int | String | Int
  

  The above definition is valid although the universe of types is just String and Int.

• Language syntax

There is one difference that stands out to me, in fact of disjoint union types. Either and Option are monads and so they give the niceties of map, flatMap and all those of a container. Can’t do that with Union types.

Update: Per phazer99‘s reddit comment, union types could be augmented with extension methods to get the map and flatMap. That’s interesting although I feel it does not make it truly monadic. For instance, what is the unit value? Will the monad laws hold good? Happy to stand corrected.

However, Union types give you edge over one thing. In fact, the thing I don’t like about Either or Option; or JVM in general. Disjoint union types are allocated on the heap; every instance. Union types are compile time construct and do not require extra allocation.

As you can see, grass is greener on either side. Both disjoint union and Union types have their place and are here to stay. You gotta choose the right one for the job; Either disjoint types | Union Types!

Know Thy Option

A thing or two about Option

• Avoid .get at all costs. Forget there is even a .get function on Option. There is always an alternative to .get. Same applies to .head
• If you are going to have access the value in an Option in a test class¹, prefer extending your test class from OptionValues. Then you can use .value on an Option, which fails with a relatively better error message if the value is not defined.
• Option maybe viewed as a sequence (of zero or one element). This is for convenience when working with Option, which is why see a .head on an Option.

Patterns for Saner Mocking

It is common to see mocks being setup this way in unit tests.

scenario("Test Case 1") {
    ...
    when(addressResolutionService.resolve(...)).thenReturn(...)
    when(vendorInventoryService.checkInventory(...)).thenReturn(...)
    ...
    .... another bunch of when and then returns
    when(shipmentService.schedule(...)).thenReturn(...)

    ...thisIsTheActualCalltoTest(...)

    verify(vendorInventoryService, 1).checkInventory(...)
    ... other such verifications
}

scenario("Test Case 2") {
    ...
    when(addressResolutionService.resolve(...)).thenReturn(...)
    when(vendorInventoryService.checkInventory(...)).thenReturn(...)
    ...
    .... another bunch of when and then returns ...give or take one or more mocks compared to the previous test ...
    when(shipmentService.schedule(...)).thenReturn(...)

    ...thisIsTheActualCalltoTest(...)

    verify(vendorInventoryService, 1).checkInventory(...)
    ... other such verifications
}

... other such test cases

Cyrilex – Online Regex Tester

A while ago, I wrote about online regex tools. Cyril (@CyrilBois) came across that post and mentioned about his regex tester tool.

I think every tool should have a name; not one that just goes by its function but a nickname, if you will. So, I am going to name Cyril’s regex tool – Cyrilex. Don’t like it, don’t worry about it.

Instead of adding Cyrilex to the list, which I have already, I took the liberty to sort of review the tool. Because it has got a few cool things that I love.

Non-FP to FP Conversion Caveat

Sometimes you learn the best from others; by watching. This post is based on such an instance. A fellow engineer on my team was investigating a nagging issue – partially-successful operations or rather operations that left data in an inconsistent state. It goes without saying that I take no credit for the time and effort spent on the investigation nor for the fix. I am just the messenger. And as a responsible programmer 🤓, I am sharing it with the rest of the world.

We use Scala in my team and have been trying to be (pure) functional (as much). Hmmm … trying to be functional? Yeah, because the truth is not always black and white.

Go away node/npm

If you haven’t found a use for this script that uninstalls the second largest junk in the world next to Mac/iOS updates, you are either lazy or scared of breaking things.  I am neither, so I polished this script from the different versions you will find on the internet. Oh, I am talking about node/npm.

Happy cleaning!

A Rambling on Error Handling

In the early years, software applications were tiny, compared to what we build today. In any given application, one could say, there were only a handful of error scenarios to deal with. Besides, error reporting, if not error handling, lacked finesse. Just slap the user with something red enough, and just say An error occurred.

JS Programming in C# – Immutability

Enough! JavaScript had us in its grip for long with its foot guns. The first time I heard the term Hoisting, I had no idea about it and misheard as hosting. You declare variables using var happily, and you have to come to peace with yourself that it is okay to hoist the vars (lift’em all to the top-most scope). I can’t believe JS convinced the rest of us that it was okay. Then came ES6 and saved us. let fixed the scoping. const provided immutability. At least now, you can say JavaScript supports functional programming.

JavaScript got feathers on its hat – let and const.

Facets of Immutability

Immutability, the cornerstone of functional programming, has many facets.

Not every (mainstream) language supports all the facets; at least not per what each facet stands for. That’s what I will talk about today. The various facets of immutability from a theoretical perspective, and briefly show how some of the mainstream languages have adopted and support these facets in their own way.

A Paradox of Braces

A great deal of thought goes into language design. Eric Lippert’s posts is a living testament, at least for C#. Syntax and idioms are also part of the language design. When designing a language, the designers have to also consider its future. For instance, when designing C#, Anders and others should have thought of and planned for what’s coming in then upcoming version(s) of C#. Such level of forethought might be seem daunting for an outsider. But the language designers are good at what they do, and most importantly, they know what they are doing. Well, in most cases!