Why did JB go with the name `Unit`? I'm not a huge...
# announcements
h
Why did JB go with the name
Unit
? I'm not a huge fan of
Void
, but I'd just as soon prefer
Blah
c
A talk from KotlinConf last year went over things like this pretty well

https://www.youtube.com/watch?v=juFkdMv4B9s

👍 1
h
including nomenclature?
r
I mean from a nomenclature perspective
Unit
seems just as reasonable as any other choice to me. It’s a unit of work that doesn’t give you anything back.
h
yeah, i never questioned it before now, because i'm writing a units of measurement DSL
and, well, it can get messy at times to overload the term
Unit
r
Ya basically everything other than
void
can be pretty easily overloaded… unless your were making some game that had an object called “Void”. That would get messy 😛.
h
well that and "Class"
because I'm also writing a D&D app, and...yeah there are classes in the game!
r
It's because it represents the unit type https://en.wikipedia.org/wiki/Unit_type Many languages have a unit type, but it can be written different ways. For languages that support tuples, it's very common to use
()
. Kotlin, being very explicit, decided to call the unit, well,
Unit
.
🤔 1
Java doesn't have a unit type, so
void
is a bit vague. It doesn't differentiate between a useless value (the unit type) and no value (called "divergent" when dealing with function returns). Kotlin does using
Unit
and
Nothing
, so you can specify a function that returns (albeit without useful info) and a function that never returns.
h
I almost never see or use
Nothing
. I think only when I leave in
TODO()
r
It's used a fair amount in the std-lib, for function like
TODO()
and
error()
. However, it's really powerful when used with generics (thanks to Kotlin's sweet usage of variance). So if you ever use
emptyList()
, it actually underneath returns a
List<Nothing>
that can be safely cast to any type.
4
It's also used in #arrow for things like
Either
h
I have actually never heard of
Either
what the heck?
h
Is this like javascript's
|
?
r
A simple version can be defined like so:
Copy code
sealed class Either<T, U> { ... }
class Left<T>(val value: T) : Either<T, Nothing> { ... }
class Right<T>(val value: T) : Either<Nothing, T> { ... }
Yeah, basically
h
That's...actually awesome
r
Indeed
h
thank you for introducing me to arrow!
or for multicatch
r
No problem. Careful though, it's a bit of a gateway drug to purely functional programming. If your not careful, soon you won't be able to talk about anything other than monads and higher kinds 🙂
h
hahah, one of my favorite things about Kotlin is how adept it is at both functional and object oriented programming
and even though it trashed programming in the 90s, now i feel like a hipster for actually liking oop
r
Agreed. Like most extremes, I find the best option is somewhere in the middle, and Kotlin has just about hit it on the nose.
💯 2
h
holy fuck, i've wanted
Option
for so long. i've never gotten around to writing the class myself
😆 1
r
And again,
None
is just
object : Option<Nothing>
h
Okay, I haven't dug in enough yet, but please tell me that you can reference members of either class when using
Either
that would be amazing, but i expect no
r
No, that wouldn't really make sense when you think about it.
Either
means it either one or the other, not both, so calling
Ether<Int, String>.subString(1)
doesn't actually make sense. You first need to check if it is
Left
or
Right
.
h
Alright
e
@Hullaballoonatic Re: Option. What does Option provide that Kotlin's nullable types doesn't provide?
r
Declarative syntax, Option.applicative, and composition
2