Monthly Archives: March 2012

The Journey of Teaching

Teaching, in any form, is a voyage, during which you reach different milestones. One of the first ones, is accomplishing that level of knowledge in order to share what you have learned with certain confidence. From then on, it is about improving, learning, correcting. It is not always about the topic, but often about finding better ways to communicate, to improve techniques to explain topics that are often complex.

One of the great joys of teaching, be it a class or giving a talk is this self-learning experience. Explaining something to someone else really helps in grasping that missing link you had; that uncertainty you weren’t sure about the first time you gave that talk. The “Ah, now I understand” moment you silently think to yourself while standing in front of your audience is very gratifying. This experience can be accomplished in many ways, such as authoring a book, writing an in-depth article or a blog post.

Although you learn as you teach, it doesn’t mean however that you can stand in front of an audience, and give a talk on a subject you’re not too familiar with, hoping to pick things up as you go along. You need to obtain that certain level of knowledge, reach that first milestone. It is a responsibility you owe not only to yourself, but also to your audience, to provide them with correct and ample information. A somewhat common joking remark is: “just make sure that you know more than everyone in the room”. Although amusing, it is a great incentive to push the limits, as it’s very hard to predicate whom your audience is, and what their background holds.

But it is important to understand that it is always a journey in which you teach but also learn. We are not born experts, whatever that term might mean.

With success comes responsibility

As we teach, we improve. As we improve we accomplish goals. These goals can be the respect of our audiences, the respect of our peers. We can start being labeled as experts around certain areas. This is encouraging and can lead to greater things. Being complimented on something we are passionate about, knowing we are succeeding is a great accomplishment, something we should be proud of. As we progress, we start to reach larger audiences. We start to embark on new areas, topics and interests.

Our prior success allows us and motivates us to embark on these new ventures. We have a faithful following. Our past experience shows that we are mostly correct in our teachings and this promotes more respect from our audiences. Our opinions are now taken as authoritative.

As this happens, we often lose sight of a fundamental thing that has made us reach this milestone in our journey: pushing ourselves in understanding things. Researching before teaching. Making sure we comprehend before explaining to others.

This is damaging. In the long run, it will lead to our own demise. The same respect we gained, we lose. But in the short time, and more importantly, we can deceive our audience. We can lead people the wrong way without us fully knowing what the right way is.

We now have a great responsibility and we need to act appropriately. Our status shouldn’t give us permission to take shortcuts, to skip milestones in our journey. We got here by building up the respect on our own merits. If we care about our audience, we should respect them back.

Skipping that first milestone openly

Not always do we have the chance or the desire to reach that first milestone before sharing our knowledge. Diverse reasons can warrant us to take a different approach when embarking on the journey of teaching. We can learn in the open. We can write about things and share that knowledge as we do our own investigation.

We should learn by asking questions. We should challenge what we learn, but do so with a proper understanding of what we are challenging. We should debate. We should be open to being proven wrong and most importantly we should learn to listen to others, much the same way we listen to our own voice, that same voice the improves our own understanding.

Arrogance won’t lead us to success, but it can lead us to failure.

The Kotlin Journey Part II: A primer on classes

2 Replies

This is a multi-part series on Kotlin, a new statically typed language from JetBrains targeting the JVM and JavaScript

Part I: Getting things set up
Part II: A primer on classes
Part III: Wrapping up classes
Part IV: Adding functionality

A small but important note

Kotlin is still work in progress and not all design decisions are final. That is why your feedback is fundamental. So please provide any feedback via this blog, via our forums, via twitter on what you like, what you dislike.

Declaring variables

Before diving into classes, let’s first see how we can declare variables in Kotlin, as we’ll eventually need to do so when creating an instance of our class.
In Kotlin, variables can be declared in one of two ways, using the var or val keyword:

var declares a variable that is mutable, that is, the value can change after it has been assigned

val declares a variable that is immutable, that is, once assigned the value cannot change

Notice that we have not declared the type. Much like the var keyword in C#, since the variable has been initialized, the compiler can infer the type. However, if we do not initialize the variable, we need to explicitly define the type:

What happens however when we declare an immutable type that has not been initialized?

As expected, the compiler will allow us to set the value, but not change it. So all is good.

Knowing now the difference between val and var, let’s move on and look at classes.

Classes

Classes are the main building blocks for many object-orientated programming languages, and as such, of Kotlin also. An empty class declaration looks pretty much like that in C# and Java

(If you’re using IntelliJ, you will see items highlighted in the gutter with an icon and letter. In this case C represents Class)

Classes can be public, private, protected or internal. By default they are internal to modules (we’ll cover what modules and accessibility levels are later). This has the initial apparent disadvantage that you would not be able to test your code from outside a module. The team is currently working on a solution for this which would involve building modules in a specific way that would allow test projects to call internal classes. The approach however will not be the same as in C# where the attribute internalsVisibleTo is required.
To use a class, we merely create an instance of it. new keyword does not exist in Kotlin. A constructor call is similar to a function call.

Note that this customer has a default constructor that takes no parameters, which in Kotlin is a known as the primary constructor. We can override this primary constructor by defining a constructor as part of the class definition

with the actual implementation contained inside the anonymous initializer. This anonymous initializer is actually only necessary when we need certain logic. If we are merely using the constructor to initialize properties, we do not need it.

Now that we know how to create a class and define constructors, let’s add some contents to the class.

Properties

Usually classes in C# and Java are composed of fields, properties, methods and nested classes. In Kotlin, classes can contain properties, methods, nested classes and object declarations. We’ll cover this last one further along in the series. However, the key thing here to notice is that Kotlin does not allow fields. As such, everything is a property. It can be internal (default), private, protected or public.

Here we have one internal property and two public ones. Notice how the internal one does not have an explicit type declaration. It is not needed. However, if we were to remove the type declaration for one of the public properties, we’d get a compiler error

The reason for this is to prevent unintentional breakage of a public API, since it’s much more likely to change the type of a property without realizing the impact it might have if it’s not explicit. Another thing to notice is that all properties require explicit initialization, irrelevant of their accessibility or whether they are mutable (var) or immutable (val).

Was that an AutoProperty?

If you’re a C# developer you’re no doubt familiar with the autoproperties, whereby the compiler internally has a backing field holding the value of a property, without requiring you to define explicit getters and setters unless you want to define explicit behavior. Kotlin is pretty much the same in that way and what we just saw uses an internal backing field which is called the same as the property but prefixed with the character $

Custom Getters and Setters

What happens when we want to provide custom behavior when reading or writing to properties? In these cases we can define getters and setters

This is an example of a customer getter which always returns “Always Jack” as the value of the property Name irrelevant of what value it has. Notice how we just define it below the property. If our getter requires more than one line, we can use a { } block.
Much like the getter, we can also define a setter. In this setter, we can write any logic that interacts with other properties of the class. But what happens when we want to interact with the actual backing field of this property (the one that the compiler creates automatically)? as mentioned before, we can use the $ prefix to access it

Setters can have different accessibility levels, by prefixing them with the corresponding keyword.

Functions

Although we won’t dive too deeply into all the different aspects of functions in this part (otherwise it would be too long of a blog post), we will see the basics to create functions as part of our classes. A function declaration, in its simplest form is:

consisting of the function name, optional parameters, optional return type and the body. Functions in Kotlin return tuples, that is they can return more than one value. When we do not specify a return type, we are implicitly saying that the return type is a Unit which is a tuple with 0 components.
Below is a full example of a class that takes two parameters in the constructor, initializes some properties and contains a function the prints out the full name.

We’ll dive deeper into functions and all the possibilities they offer in a different post.

Summary

In this second part, we’ve covered the basics of classes, how to declare one, how constructors work and how to define properties and functions. Classes in Kotlin however offer much more and there’s a lot more to learn about them. In other parts we’ll cover the difference between open and final classes (hint: default is final), abstract classes, inheritance, as well as traits, which are somewhat similar to interfaces in C#.

Windows 8 Everywhere?

1 Reply

I posted this on Twitter today.

If it’s not blatantly clear, that’s me trying to scroll through a Windows 8 Consumer Preview screen installed on a Virtual Machine, using my fingers.

Of course, it doesn’t work. Not because of the VM. It doesn’t work because my desktop isn’t a touch screen. However, it feels like it should work. But, it doesn’t. That leaves me with the alternative to use a mouse, and so far it’s not been a good experience.

When I posted this, people assumed I was joking. Sure, I realize it doesn’t work. But my point wasn’t a joke. Microsoft is trying to push this everywhere and I feel this kind of interface doesn’t make sense unless it’s on a touch screen.

That’s one difference between Apple and Microsoft. Apple realize one size (OS) doesn’t fit all. Microsoft thinks it will. Time will tell. However, as it stands now, it’s going to be difficult.

Hadi Hariri's Blog