Okay. So, hello everyone. Welcome to this new talk. Uh, my name is Matteo Orlandi. I'm here with Luca Caputo and we're both mobile developers at WD.

And today we're going to talk about types, specifically uh, structural and nominal type systems.

And uh, what a better way to start than a coding session. So let's pretend that for today my assignment is to create a function that sends emails.

So I would rather start with my type `Email` is pretty easy. My function `sendEmail`. It's something that should look like this.

Sorry, it's quite difficult to write like this. So let's say that for the moment, `console.log` is perfect for our use case.

And so let me call my `sendEmail` with some hello box. What do you think about it? Isn't it beautiful?

It's nice. But I see that you just created a type alias. So I can just say, let's call this `sendEmail` function but this time let's say, let's say `invalidEmail`.

And as you can see, okay, it's quite weak. I I see your point.

I think that maybe I should upgrade my type. And what about something like this? Sorry. And take a look at here, a beautiful union of string literal.

And as you can see, now yours is failing. And let me just, I can go also international. Ah, cool.

See, uh, that's nice. You broke my invocation here. But I can still uh, sorry, mess it up. So what about really using some illegal characters?

Huh? Works. So I pitch you an idea. How about we stop delegating validation and actual logic to types and switch the real thing.

Huh? No way. Sorry. Maybe we just run some validation logic here and then just set.

Okay, how about this? Okay, let's say maybe you're right, but let's stop for a second, and this example is done, is over.

And let me say, of course, that this was intentionally easy. But I guess that maybe someone did not felt the same about this.

Of course, I think that most of you think that this actually makes sense, but maybe someone is thinking, what are you doing? Why is this even possible?

And so, same code but different reactions, and it's not about, I mean, it's something that has nothing to do with the syntax or the code complexity.

I think that we are looking at the smallest and simplest example of a bigger problem that is, should I go with a structural or a nominal type system?

And so, here today, we're not here to get a winner, actually to pick a winner, but instead, we should try to understand what approach we should choose, you know, to design our APIs, to conduct our PRs, PR reviews, of course, and maybe also how we should argue with our colleagues.

So, without further ado, let's get started with the actual talk.

For today's, so for today's agenda, let's say that we're going to start with some languages. So we're going to mention some of them that are actually implementing structural and nominal type systems.

We're going to try to define what is a structural type system and what a nominal one is.

Maybe we're going to discover which one is best. But to get there, I think that we're going to make some final findings.

And finally, we're going to leave you with some takeaways. So, let me start with the structural type system.

And I would rather start with this quote. And this quote, if it quacks, it's a duck. It's something that really defines how structural type systems work.

And it's something that comes from the duck test. It is something that is applied to an unknown subject.

So to study it, we're going to look at how it exhibits, it acts, it sounds. So we can say that if it quacks, most probably it's a duck.

So before starting defining what a structural type system is, let's meet our languages.

So we have three ducks and one is TypeScript, one is Go and one is OCaml. And to better define what a structural type system is, let's go through some common scenarios and use cases.

I would start with the most common one, I think that is API integration.

So when you have to deal with external and untyped data, and using a nominal type system, what you have to do probably is to create some adapters, some mappings.

And with a structural type system, it's nothing that you can do like that.

And so it makes a good, it is a good example of usage for this type.

And another example is the interoperability between objects and third-party libraries and also for functional programming and also for algebraic data types. So next up there are some examples that of course, let me say, are super easy.

They are just meant to, you know, go through some of their of the features of these uh systems.

So let's get started with the first one that is with TypeScript. And what we're doing here, we are we have uh two different um structures, very similar actually.

And at line seven, I'm assigning a value to my user A uh constant. And after that, I'm assigning the user A to the user B.

And it actually, it's a legal operation because the uh structure of user A satisfies the structure of user B. So this is a um good example of interoperability.

Let's step forward with Go. Uh so here we have um a product struct with uh two easy simple uh fields.

And in my function here, we can see that I'm creating two different products and one has only one field. And this is because I don't need uh constructors.

And also this means that uh I'm able to um put values uh on the Go, on the fly. Uh so I can dynamically create my objects.

And also uh Go here helps us um with a a feature that um in that at line 13, we are printing printing the color field without even assigning it a value.

And this is because Go automatically assigns a default value. This is an empty string.

And finally, we see with OCaml, uh here we got uh some type that is uh an algebraic type data type that let us our model explicitly.

So we have we get one type or another one. And of course, we could do what we could do is also an intersection.

And of course, we are uh using it for example, uh in um pattern matching. And Luca, tell me something about the nominal type systems.

Yeah, we went through some pretty cool examples of structural type systems, but as you saw, uh these systems give you a lot of flexibility. So they may have use cases such as prototyping or having large integrations with many services and stuff.

But sometimes having this kind of flexibility can be actually a bad a bad thing.

We maybe want some strictness. We want to ensure some rules and something like that. So, first off, as before, we're going to go through some examples of programming languages that implement the actual nominal type system.

So the first one here, this one runs on three billion devices and counting.

This is Java. Then we get this natural evolution, which is Kotlin.

And then we got the Microsoft flavor, which is C#. So let's go through some common use cases and scenarios. First off, we want to ensure identity and authenticity of data by assigning it a label, a name.

We actually are saying that it's not enough to match the shape of an object.

We actually need also to match its name, its label. So this makes it impossible to swap types dynamically, even if we don't want to.

Then we got explicit subtyping, meaning that when we define a class or an interface, we got if we want to extend it, if you want to inherit their actual fields and functions and whatever, we have to explicitly extend that class.

Meaning that if there's an object that we think it's a subtype of something, if it's not explicitly declared in the blueprint, so the interface or the class, we cannot actually call that method even though maybe it exists.

And lastly, we get a name as an abstraction boundary, meaning that the name itself is a contract, meaning that when we read something, we get all the information we need from the label of the type itself.

So let's go over some examples. Uh, this one is Java, and as we can see, we get on line one and on line 10, we get two different classes.

One is User ID, and the other one is an Order ID.

If we take a closer look at the actual body of the class, we see that their implementation is exactly the same.

So everyone gets an int, uh, an integer as a value, and everyone has this getter. So we get this `getValue` that just returns this field.

But then we look at the main program here, and we define a function which is `getUser`, and this one accepts only a User ID.

So when we try to actually call the function on line 27 and 28, we see that User ID and Order ID, uh, one fails and the other one succeeds.

And that's what we want actually, because maybe we're trying to do a query on a database, and what if we passed something that refers to an order, we get something messy.

So this ensures that we do what we actually want.

Let's see another example here. We're using Kotlin, and we define a class here which is called `Shape` that has a function called `area`.

Easy enough. Then we define a second class. This one is `Circle`, and we extend the `Shape` class.

This time, we actually override the `area` function by redefining it. So when we define our new function `printArea`, we take in a shape and just print out the actual area.

As we can see on line 15, when we call `printArea`, the compiler gives us a green light.

because we're passing in a circle which explicitly defines `Shape` as its parent type. This is something that wouldn't happen on a structural type system.

Everything that has the method `Area` in it would be just perfectly fine. And that's, uh, and that's dangerous actually because if we're trying to model something like a shape, we just want to calculate the area of a shape.

There may be many things that have `Area` outside of shapes and that's not what we want to calculate.

So let's go to C# here, and as you can see here we get the, uh, structure, the `UserToken`, which has a private read-only string field which is called `Token`, and then we have a constructor and a function which is called `Authenticate`.

The, the, the program class here, uh, defines a second function which is `AccessService` that takes in a specific `UserToken`.

And when we try to call the function, everything works fine because we're just instantiating a new `UserToken` on line 21. And on line 23, if we try to access the token itself, the compiler is going to give us an error because, uh, as you can see on line two, `Token` is actually a private field.

So this gives us, uh, the name of the function is itself the abstraction boundary, the name of the class. So the name of the type defines what is visible from the outside.

Any internal implementation details are hidden. So if we change the internal implementation, nothing is going to break as long as we stick to the contract.

And so this guarantees us safety, safe refactoring, and controlled polymorphism.

So the natural questions here after seeing structural type system, nominal type system, some example, the natural question that arises is, which one is best.

Is anybody here who knows the answer? Nominal. Okay. It depends. The politically correct answer is, it depends.

So basically, why it depends? It depends because for different goals, we get different trade-offs, and this is because every type system shines in its own ecosystem.

But if I try to give you a better answer to the previous question, I would rather say that the better model, the better system, is the one that fits your constraint, your context, and also maybe your coding style.

But let's try to better understand when a structural type system is better than a nominal one.

And for today, we brought you an example of a declarative query language. And so what we're going to do is to create somewhat like an ORM.

And by starting from a simple model, we're going to create some different types, some smart types, very smart types, I assure you, and we're going to derive and calculate the final type from the operations.

So let's get started. This is our super simple model. We get a user. There's an ID, but I would rather focus on the username and the age field, since one is a string field and one is a number one.

And so let's start with the very basic operation in our query language that is the select.

I think that any of you here knows what we're trying to do. And so the question is, how should I type my select function?

And I can do something like this. And so by checking on my generic T, I can say that my select function is an array of keys of that T.

And so what I get after passing it to my select function is that I get some static validation by my IDE.

So I will not be able to pass something that is not inside my actual entity, that is in this case our user.

And also on top of that, I'm going to get a resulting type that is directly calculated from what I just did.

So it will be dynamically, you know, if I'm going to omit the ID, my resulting type is going to be including only the username.

So let's try to add some flavor to our functions and let's go with a filter. So a where condition and again we are using, we are checking on age and username field and are specific in this example since one is a number and one is a string.

So what we should do is to assign some different operations on those fields and so let's try to create some new types for our numeric operation.

In this case we get an EQ, um, less than, greater than, and a between range.

And for example, instead for our string operations, we can get again an EQ, so an equal or a contains.

And if we try to combine them, we can create something like this. So my type where operations gets again a generic T. And if that particular field that I'm working on is a number, I'm going to use only numeric operations, otherwise string operations.

Hold on a minute. And what happens if my T is actually something like a boolean?

You're just considering number here. >> Yeah, of course, I was about to say it.

Type Clash: When Structural and Nominal Systems Collide by Matteo Orlandi and Luca Caputo

Devoxx Belgium 2024 : 7 - 11th of October in Antwerp
More info @ https://devoxx.be 


Type Clash: When Structural and Nominal Systems Collide by Matteo Orlandi and Luca Caputo

Scripts