Scala’s Types of Types

This blog post came into being after a few discussions about Types in Scala after some of JavaOne’s parties in 2013. After those discussions I figured that many questions are often repeated by different people, during their learning of Scala. I though that we didn’t have a full list of all tricks what we can to with Types in Scala, so I decided to write such a list - giving real life examples why we’d need these types.

While I’m working on this article since quite some time, there’s still MUCH to do! For example Higher Kinds need a rewrite, there’s a lot of detail to be added in Self Type’s and lots and lots more. Check the todo file for more.

If you’d like to help, please do! I’ll welcome any pull request, or suggestion (well, I’d prefer pull requests ;-).

Also, if you see a section marked with "✗" it means that it needs re-work or that it’s not complete in some way.

Scala has Type Inference, which means that we can skip telling the Type of something each time in the source code, and instead we just use `val`s or `def`s without "saying the type explicitly in the source". This being explicit about the type of something, is called a Type Ascription (sometimes called a "Type Annotation", but this naming convention can easily cause confusion, and is not what is used in Scala’s spec).

In these situations, leaving out the Type Ascription is OK. Although you may decide to always ascribe return types of public methods (that’s very good idea!) in order to make the code more self-documenting.

In case of doubt you can refer to the below hint-questions to wether or not, include a Type Ascription.

So we put Type Ascriptions after value names. Having this said, let’s jump into the next topics, where these types will become more and more interesting.

We refer to a Scala’s typesystem as being "unified" because there is a "Top Type", Any. This is different than Java, which has "special cases" in form of primitive types (int, long, float, double, byte, char, short, boolean), which do not extend Java’s "Almost-Top Type" - java.lang.Object.

Scala takes on the idea of having one common Top Type for all Types by introducing Any. Any is a supertype of both AnyRef and AnyVal.

AnyRef is the "object world" of Java (and the JVM), it corresponds to java.lang.Object, and is the supertype of all objects. AnyVal on the other hand represents the "value world" of Java, such as int and other JVM primitives.

Thanks to this hierarchy, we’re able to define methods taking Any - thus being compatible with both scala.Int instances as well as java.lang.String:

For the Typesystem it’s transparent, though on the JVM level once we get into ArrayBuffer[Any] our Int instances will have to be packed into objects. Let’s investigate the above example’s by using the Scala REPL and it’s :javap command (which shows the generated bytecode for our test class):

You’ll notive that myInt is still carrying the value of a int primitive (this is visible as I at the end of the myInt:()I invokevirtual call). Then, right before adding it to the ArrayBuffer, scalac inserted a call to BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer (a small hint for not frequent bytecode readers, the method it calls is: public Integer boxToInteger(i: int)). This way, by having a smart compiler and treating everything as an object in this common hierarchy we’re able to get away from the "but primitives are different" edge-cases, at least at the level of our Scala source code - the compiler takes care of it for us. On JVM level, the distinction is still there of course, and scalac will do it’s best to keep using primitives wherever possible, as operations on them are faster, and take less memory (objects are obviously bigger than primitives).

On the other hand, we can limit a method to only be able to work on "lightweight" Value Types:

In the above example I’ve used a TypeClass Checker[T] and a type bound, which will be discussed below. The general idea is that this method will only take Value Classes, be it Int or our own Value Type. While probably not used very often, it shows how nicely the typesystem embraces java primitives, and brings them into the "real" type system, and not as a separate case, as is the case with Java.

In Scala everything has "some" type… but have you ever wondered how the type inferencer can still work, and infer sound types when working with "weird" situations like throwing exceptions? Let’s investigate the below "if/else throw" example:

As you can see in the comments, the type of the if block is Int (easy), the type of the else block is Nothing (interesting). The inferencer was able to infer that the thing value, will only ever be of type Int. This is because of the Bottom Type property of Nothing.

Type inference always looks for the "common type" of both branches in an if stamement, so if the other branch here is a Type that extends everything, the infered type will automatically be the Type from the first branch.

The same reasoning can be applied to the second Bottom Type in Scala - Null.

The type of thing is as expected, String. Null follows ALMOST the same rules as Nothing. I’ll use this case to take a small detour to talk about inference, and the differences between AnyVals and AnyRefs.

Let’s think about Int and other primitives, which cannot hold null values. To investigate this case let’s drop into the REPL and use the :type command (which allows to get the type of an expression):

This is different than the case with a String object in one of the branches. Let’s look into the types in detail here, as Null is a bit less "extends everything" than Nothing. Let’s see what Int extends in detail, by using :type again on it:

The verbose option adds a bit more information here, now we know that Int is an AnyVal - this is a special class representing value types - which cannot hold Null. If we look into AnyVal’s sources, we’ll find:

I’m bringing this up here because the core functionality of AnyVal is so nicely represented using the Types here. Notice the NotNull trait!

Coming back to the subject why the common Type for our if statement with an AnyVal on one code block and a null on the other one was Any and not something else. The one sentence way to define it is: Null extends all AnyRefs whereas Nothing extends anything. As AnyVals (such as numbers), are not in the same tree as AnyRefs, the only common Type between a number and a null value is Any - which explains our case.

Scala `object`s are implemented via classes (obviously - as it’s the basic building block on the JVM), but you’ll notice that we cannot get its type the same way as we would with an simple class…

I would surprisingly often get the question on how to pass an object into a method. Just saying obj: ExampleObj won’t work because that’s already referring to the instance, so there’s a member called type which should be used in such cases.

How it might look like in your code is explained by the below example:

Variance, in general, can be explained as "type compatible-ness" between types, forming an extends relation. The most popular cases where you’ll have to deal with this is when working with containers or functions (so… surprisingly often!).

A major difference from Java in Scala is, that container types are not-variant by default! This means that if you have a container defined as Box[A], and then use it with a Fruit in place of the type parameter A, you will not be able to insert an Apple (which IS-A Fruit) into it.

Variance in Scala is defined by using + and - signs in front of type parameters.

http://www.slideshare.net/dgalichet/demystifying-scala-type-system

The above table ilustrates all variance cases we’ll have to worry about - in an abstract way. In case you’re wondering where you’d have to care about this - in fact, you’re exposed to this each time you’re working with collections you’re being faced with the question "is it covariant?".

There are (at least) two nice and very intuitive examples of this in Scala. One being "any collection", where we’ll use a List[+A] as our example, and functions. When talking about List in Scala, we usually mean scala.collection.immutable.List[+A], which is immutable as well as covariant, let’s look how this relates to building lists containing items of different types.

It’s worth mentioning that while having immutable collections co-variant is safe, the same cannot be said about mutable collections. The classic example here is Array[T] which is invariant. Let’s look at what invariance means for us here, and how it saves us from mistakes:

Such an assigment won’t compile, because of Array’s invariance. If this assignment would be valid, we’d run into the problem of being able to write such code: a(0) = "" // ArrayStoreException! which would fail with the dreaded ArrayStoreException.

Refinements are very easy to explain as "subclassing without naming the subclass". So in source code it would look like this:

Package Objects have been added to Scala in 2.8 Package Object and do not really extend the type system as such, but they provide an pretty useful pattern for "importing a bunch of stuff together" as well as being one of the places the compiler will look for implicit values.

Declaring a package object is as simple as using the keywords package and object in conjunction, such as:

It’s a custom to put package object’s in a file called package.scala into the package they’re the object for. Investigate the above example’s source path and package to see what that means.

On the usage side, you get the real gains, because when you import "the package", you import any state that is defined in the package side along with it:

It’s not really another kind of type, but a trick we can use to make our code more readable:

Using this trick the Map definition now suddenly "makes sense!". If we’d just used a String => Int map, we’d make the code less readable. Here we can keep using our primitives (maybe we need this for performance etc), but name them so it makes sense for the future reader of this class.

Let’s now go deeper into the use cases of Type Aliases, which we call Abstract Type Members.

With Abstract Type Members we say "I expect someone to tell me about some type - I’ll refer to it by the name MyType". It’s most basic function is allowing us to define generic classes (templates), but instead of using the class Clazz[A, B] syntax, we name them inside the class, like this:

Which for Java folks may seem very similar to the Container<A> syntax at first, but it’s a bit more powerful as we’ll see in the section about Path Dependent Types, as well as in the below example.

It is important to notice that while in the naming contains the word "abstract", it does not behave exactly like an abstract field - so you can still create a new instance of SimplestContainer without "implementing" the type member A:

You might be wondering what type A was bound to, since we didn’t provide any information about it anywhere. Turns out type A is actualy just a shorthand for type A >: Nothing <: Any, which means "anything".

So we "provide the type" using a Type Alias, and now we can implement the value method which returns an Int.

The more interesting uses of Abstract Type Members start when we apply constraints to them. For example imagine you want to have a container that can only store anything that is of a Number instance. Such constraint can be annotated on a type member right where we defined it first:

Or we can add constraints later on in the class hierarchy, for example by mixing in a trait that states "only Numbers":

So, as you can see we can use Abstract Type members, in similar situations like we use Type Parameters, but without the pain of having to pass them around explicitly all the time - the passing around happens because it is a field. The price paid here though is that we bind those types by-name.

Self-recursive Types are referred to as F-Bounded Types in most literature, so you may find many articles or blog posts refering to "F-bounded". Actually, this is just another name for "self-recursive" and stands for situations where the subtype constraint itself is parametrized by one of the binders occurring on the left-hand side. Since the wording self-recursive is more intuitive, let’s stick to it for the rest of the section (while the subsection title being aimed for people who try to google what "F-bounded" means).

Type Constructors act pretty much like functions, but on the type level. That is, if in normal programming you can have a function that takes a value a and returns a value b based on the previous one, then in type-level programming you’d think of a List[+A] being a type constructor, that is:

Using this example, you can see how similar it is to normal constructors - with the only difference that here we work on types, and not instances of objects. It’s worth reminding here that in Scala it is not valid to say something is of type List, unlike in Java where javac would put the List<Object> for you. Scala is more strict here, and won’t allow us to use just a List in the place of a type, as it’s expecting a real type - not a type constructor.

Related to this subject is that with Scala 2.11.x we’re getting a new power user command in the REPL - the :kind command. It allows you to check if a type is higher kind or not. Let’s check it our on a simple type constructor, such as List[+A] first:

Here we see that scalac is able to tell us that List, in fact, is a type constructor (it’s way more talkative when used with the -verbose option). Let's investigate the syntax right above this information: `* -> *. This syntax is widely used to represent kinds, and actually I found it quite Haskell inspired - as this is the syntax Haskell uses to print types of functions. The most intuitive way to read it out loud would be "takes one type, returns another type". You might have noticed that we’ve omitted something from Scala’s exact output, the plus sign from the relation (as in:* -(+)-> *), this means variance bounds and you can read up in detail about variance in section Type Variance in Scala.

As already mentioned, List[+A] (or Option[+A], or Set[+A]… or anything that has one type parameter) is the simplest case of a type constructor - these take one parameter. We refer to them as first-order kinds (* -> *). It’s also worth mentioning that even a Pair[+A, +B] (which we can represent as * -> * -> *) is still not a "higher-order kind" - it’s still first-order. In the next section we’ll dissect what exactly higher kinds give us and how to notice one.

Higher Kinds on the other hand, allow us to abstract over type constructors, just like type constructors allow us to abstract over the type they.

A classic example here is a Monad:

TODO: http://blogs.atlassian.com/2013/09/scala-types-of-a-higher-kind/

Case Classes are one of the most useful nifty little compiler tricks available in Scala. While not being very complicated, they help a lot with otherwise very tedious and boring things such as equals, hashCode and toString implementations, and also preparing apply / unapply methods in order to be used with pattern matching, and more.

A case class is defined just like a normal class in Scala, but prepended with the case keyword:

Just by this one line, we have already implemented the Value Object pattern. This means that by defining a case class we automatically get these benefits:

Let’s see what we got so far, and expand on this using a "real life" example, this time implementing a Point class, because we’ll beed more than just one field to show off some interesting features case class provides us with:

Not only that, but a case class is ready to be used with pattern matching, using either the "usual" or "extractor" syntax:

Scala does not have a build in "enum" like Java does. Instead we use a few tricks (embedded in Enumeration) to write something pretty similar.

Value classes have been around in Scala for a long time internally, and you’ve used them already many times because all Number’s in Scala use this compiler trick to avoid boxing and unboxing numeric values from int to scala.Int etc. As a quick reminder, let’s recall that Array[Int] is an actual JVM int[] (or for bytecode happy people, it’s the JVM runtime type called: [I) which has tons of performance implications, but in one word — arrays of numbers are fast, arrays of references not as much.

Ok, since we now know the compiler has fancy tricks to avoid boxing ints into Ints when it doesn’t have to. Let’s see how this feature is exposed for us, end users since Scala 2.10.x. The feature is called "value classes", is fairly simple to apply to your existing classes. Using them is as simple as adding extends AnyVal to your class and following a few rules listed bellow. If you’re not familiar with AnyVal, this might be a good moment for a quick refresher by looking at Section Unified Type System - Any, AnyRef, AnyVal.

For our example let’s implement a Meter which will serve as wrapper for plain Int and be able to convert the number of meters, into the number of type Foot. We need this class because no-one understands the imperial unit system ;-) On the downside though, why should we pay the runtime overhead of having an object around an int (that’s quite a few bytes (!) per instance) if for 95% of the time we’ll be using the plain meter value - because it’s a project for the european market? Value classes to the rescue!

We’ll be using Case (Value) Classes in all our examples here, but it’s not technically required to do so (although very convinient). You could implement a Value Class using a normal class with one val parameter instead, but using case classes is usually the best way to go. Why only one parameter you might ask — this is because we’ll try to avoid wrapping the value, and this only makes sense for single values, otherwise we’d have to keep a Tuple around somewhere, which gets fuzzy very quickly and we’d loose the performance of not-wrapping anyway. So remember - value classes work only for 1 value, although no-one said that that parameter must be a primitive (!), it can be a normal class, like Fruit or Person, we’ll still be able to avoid wrapping it in the Value Class at some times.

Ok, so now that we got our Meter and Foot Value Case Classes, let’s first examine how the generated bytecode has changes from a normal case class when we added the extends AnyVal part, making Meter a value class:

And the bytecode generated for the value class bellow:

There’s basically one thing that should catch our attention here, it’s that the Meter’s companion class when created as a Value Class, has gained a new method - toFeet$extension(double): Foot. Before this method was an instance method, of the Meter class, and it did not take any arguments (so it was: toFeet(): Foot). The generated method is marked as "extension", and this is actualy exactly the name we give to such methods (.NET developers might see where this is headed already).

As our goal with Value Classes is to avoid having to allocate the entire value object, and instead work directly on the wrapped value we have to stop using instance methods — as they would force us into having an instance of the Wrapper (Meter) class. What we can do instead is promoting the instance method, into an extension method, which we’ll store in the companion object of Meter, and instead of using the value: Double field of the instance, we’ll pass in the Double value each time we’ll be calling the extension method.

Let’s now use our newly gained knowlage and investigate what the compiler will actualy do for us in the Meter example. Right next to the source code "as we write it", the comments will be explaining what the compiler actualy generates (thus, what happens when we run this code):

These are the basics around extension methods and value classes. If you want to read more about the different edge-cases around them, please refer to the official documentaion’s section about Value Classes where Mark Harrah, explains them very well with tons of examples, so I won’t be duplicating his effort here beyond the basic introduction :-)

Type Classes belong to the most powerful patterns available to use in Scala, and can be summed up (if you like fancy wording) as "ad-hoc polimorphism" which should be understandable once we get to the end of this section.

The typical problem Type Classes solve for us is providing extensible APIs without explicitly binding two classes together. An example of such a strict binding, we would be able to avoid using Type Classes, is for example extending a Writable interface, in order to make our custom data type writable:

Using this style, of just extending and implementing an interface, we have bound our Num to Writable and also, we had to provide the implementation for write, "right there, right now", which makes it harder for others to provide a different write implementation - they would have to subclass Num! Another pain point here is that we cannot extend two times from the same trait, providing different serialization targets (you can’t both extend Writable[Json] and Writable[Protobuf]).

All these problems can be addressed by using a Type Class based approach instead of directly extending Writable[Out]. Let’s give it a shot, and explain in detail how this is actually working:

Universal traits are traits that extend Any, they should only have `def`s, and no initialization code.

TODO TODO

Self Types are used in order to "require" that, if another class uses this trait, it should also provide implementation of whatever it is that you’re requiring.

Let’s look at an example where a service requires some Module which provides other services. We can state this using the following Self Type Annotation:

The second line can be read as "I’m a Module". It might seem yield the exactly same But how does this differ from extending Module right away?

which means that someone will have to give us this Module at instantiation time:

If you were to try to instantiate it without mixing in the required trait it would fail like this:

You should also keep in mind that it’s OK to specify more than one trait when using the self-type syntax. And while we’re at it, let’s discuss why it is called self-type (except for the "yeah, it makes sense" factor). Turns out a popular style (and possibility) to write it looks like this:

In fact, you can use any identifier (not just this or self) and then refer to it from your class.

Phantom Types are very true to it’s name even if it’s a weird one, and can be explained as "Types that are not instantiate, ever". Instead of using them directly, we use them to even more strictly enforce some logic, using our types.

The example we’ll look at is a Service class, which has start and stop methods. Now we want to guarantee that you cannot (the type system won’t allow you to) start an already started service, and vice-versa.

Let’s start with preparing our "marker traits", which don’t contain any logic - we will only use them in order to express the state of an service in it’s type:

Note that making the ServiceState trait sealed assures that no-one can suddenly add another state to our system. We also define the leaf types here to be final, so no-one can extend them, and add other states to the system.

Having those prepared, let’s finally dive in into using them as Phantom Types. First let’s define a class Service, which takes State type parameter - notice here that we don’t use any value of type S in this class_! It’s just there, unused, like a ghost, or Phantom - which is where it’s name comes from.

So in the companion object we create a new instance of the Service, at first it is Stopped. The Stopped state conforms to the type bounds of the type parameter (<: ServiceState) so it’s all good.

The interesting things happen when we want to start / stop an existing Service. The Type bounds defined on the start method for example, are only valid for one value of T, which is Stopped. The transistion to the opposite state is a no-op in our example, we return the same instance, and explicitly cast it into the required state. Since nothing is actualy using this type, you won’t bump into class cast exceptions during this conversion.

Let’s now investigate the above code using the REPL, which will act as a nice finisher for this section.

As you see, Phantom Types are yet another great facility to make our code even more type-safe (or shall I say "state-safe"!?).

Strucural Types are often described as "type-safe duck typing", which is quite a good comparison if you want to gain some intuition for it.

So far we’ve only been thinking about types in terms of "does it implement interface X?". With structural types we can go a step further and start reasoning about the structure of a given object (hence the name). When checking whether a type matches using structual typing, we need to change our question to:"does it have a method with this signature?".

Let’s look at a very popular use-case in action, to see why it is so powerful. Imagine that you have many classes of things that can be closed. In Java-land one would usually implement the java.io.Closeable interface in order to make it possible to write some common Closeable utility classes (in fact, Google Guava provides such a utility class). Now imagine that someone also implemented a MyOwnCloseable class but didn’t extend java.io.Closeable. Your Closeables library would not work here due to the static typing. You would not be able to pass instances of MyOwnCloseable into it. Let’s solve this problem using Structural Typing:

The structural type is defined as a parameter to the method. It basically says that the only thing we expect from the type is that it should have this method. It could have more methods - so it’s not an exact match but the minimal set of methods a type has to define in order to be valid.

Another fact to keep in mind when using Structural Typing is that it actually has huge (negative) runtime performance implications, as it is actually implemented using reflection. We won’t look into the byte code for this case, but remember that it’s very easy to investigate the generated bytecode for scala (or java) classes, by using :javap in the Scala REPL. So you should try this out yourself.

Before we move over to the next subject, let’s briefly touch on a small but neat style tip. Imagine that your Structural Type is quite big, an example would be a type representing something that you can open, work on, and then must close. By using a Type Alias (described in detail in another section) with a Structural Type, we’re able to separate the type definition from the method, where we want to take in such instance:

By using this type alias we’ve made the def much cleaner. I’d highly recommend type aliasing bigger structural types. And one last warning, always check if you really need to reach for structural typing, and cannot do it in some other way, considering the negative performance impact.

This Type allows us to type-check on a Type internal to another class. This may seem weird at first, but is very intuitive once you see it:

The ey to understand here is that "each Outer class has its own Inner class", so it’s a different Type - dependent on which path we use to get there.

Using this kind of typing is useful, we’re able to enforce getting the type from inside of a concrete parameter. An example of a signature using this typing would be:

Using the path dependent type we have now encoded in the type system, the logic, that this container should only contain children of this parent - and not "any parent".

We’ll see how to require the "child of any parent" Type in the section about Type Projections soon.

Type Projections are similar to Path Dependent Types in the way that they allow you to refer to a type of an inner class. In terms of syntax, you path your way into the structure of inner classes splitting them with a # sign. Let’s start out by showing the first and main difference between these path dependent types (the "." syntax) vs. type projections (the "#" syntax):

Another nice intuition about path dependent vs. projections is that Type Projections can be used for "type level programming" ;-) == Existential Types

Existential Types are something that deeply relates to Type Erasure, which JVM languages "have to live with".

We don’t know the type of a, because of runtime type erasure. We know though that List is a type constructor, * -> *, so there must have been some type, it could have used to construct a valid List[T]. This "some type", is the existentional type!

Scala provides a shortcut for it:

Let’s say you’re working with some Abstract Type Member, that in our case will be some Monad. We want to force users of our class into using only Cool instances within this Monad, because for example, only for these Types our Monad has any meaning. We can do this via Type Bounds on these Existential Type T:

http://mikeslinn.blogspot.com/2012/08/scala-existential-types.html

In type lambda’s we’ll be using Path Dependent as well as Structural Types, so if you skipped that sections you may want to go back to it.

Before we look at Type Lambdas, let’s take a step back and remind ourselfs a bit about functions and currying.

Let’s start discussing this Type by remembering set theory, and viewing the already known construction A with B as "Intersection Type":

Why? Well, the only objects that conform to this type are those who have the type A and type B, so in set theory, this would be an intersection. On the other hand, let’s think what an Union Type is then:

It’s an union of these two sets, so set wise it’s an type A or type B. Our task at hand is to introduce such type using Scala’s type system. While not being a first-class construct in Scala (it’s not built in) they are pretty easy to implement and use ourselfs. Miles Sabin explains this technique in depth in the blog post Unboxed union types in Scala via the Curry-Howard isomorphism if you’re curious for an in-deptht explanation.

Since we started talking about the "weird" types in Scala, we can’t let this one go without a dedicated section for it. DelayedInit is actually a "compiler trick" above anything else, and not really tremendously important for the type system itself, but once you understand it, you’ll know how scala.App actually works, so let’s dive into our example with App:

By looking at this code, and applying our basic Scala knowlage to it we might think "Ok, so the println is actualy in the constructor of the Main class!". And this would usually be true, but not in this case, since we inherited the DelayedInit trait - as App extends it:

And let’s take a look at the full source code of the DelayedInit trait right away:

As you can see, it does not contain any implementation - all the work around it is actually performed by the compiler, which will treat all classes and objects inheriting DelayedInit in a special way (note: trait’s will not be rewriten like this). The special treatment goes like this:

Let’s quickly give an example for this, and then we’ll re-implement what App does for us, but by hand (and the help of delayedInit):

Using this mechanism you can run the body of your class whenever you want (… maybe never?). Since we now know how delayedInit works, let’s implement our own version of scala.App (which actually does it in exactly the same way).

That’s it. Since the rewriting is not applied to traits, the code we see in our SimpleApp will not be modified by extending DelayedInit, thanks to this, we can make use of the delayedInit method and accumulate any "class bodies" that we encouter (imagine we’re dealing with a deep hierarchy of classes here, then the delayedInit would be called multiple times), and then we simply implement the main method like you would in plain Java land.

I’ve had a hard time trying to decide if I should put this type into this vademecum of types or not. Lastly, I decided to add it, since it would make this collection of Type descriptions complete. So the question is, why did I hesistate so much?

Scala allows us to have Dynamic Types, right inside of a Staticly/Strictly Typed language! Which is why I was considering to skip it, and leave a separate place for it’s description - as it’s basically "hacking around" all the descriptions you’ve seen above ;-) Let’s see it in action though, and how it fits into the Scala Type-ecosystem.

Imagine a class JsonObject which contains arbitrary JSON data. Let’s have methods, matching the keys of this JSON object, which would return an Option[JValue], where a JValue can be another JObject, JArray or JString / JNumber. The usage would look like the example below.

But before that, remember to enable this language feature in the given file (or REPL) by importing it. There are a few features (like the experimental macros for example) that need to be explicitly imported in a file to be enabled. If you want to know more about these features, take a look at the [scala.language](http://www.scala-lang.org/api/current/index.html#scala.language$) object or read the Scala Improvement Process 18 document ([SIP-18](https://docs.google.com/document/d/1nlkvpoIRkx7at1qJEZafJwthZ3GeIklTFhqmXMvTX9Q/edit)).

So… how do we fit this into an otherwise Statically Typed language? The answer is simple - compiler rewrites and a special marker trait: scala.Dynamic.

Ok, end of rant and back to the basics. So… How do we use Dynamic? In fact, it’s used by implementing a few "magic" methods:

Let’s take a look (with examples, at each of them. We’ll start with  the most "typical one", and move on to those which would allow the construct shown above (which didn’t (back then) compile) and make it work this time ;-)