Apple, Let’s Talk About “Explicit” and “Implicit”

Dear Apple,

I’m one of the guys who goes around saying “Apple API is one of the easiest GUI APIs I ever used”. Even when people complain about Objective-C, I point that since everything is a canvas, you can extended every component in any imaginable way.

I also get why Table Views go under the Navigation Bar, Tool Bar and Status Bar: To give the user the impression that the application stretches over all the screen instead of a small space in the middle.

But there is one thing I learnt with Python: Explicit is better than Implicit.

When you automatically add the default padding to an element dragged in the storyboard, I can see the padding in the Size inspector; when I set a relationship between two elements, I can see the constraint in the same Size inspector.

But when I drag a Table View to my View Controller and it automagically gets a padding to go under the navigation bar and there is nowhere to see this, then we have a problem.

When a UITableView is the first subview of the main view, it magically gets a padding; this is shown nowhere.

When a UITableView is the first subview of the main view, it magically gets a padding; this is shown nowhere (except in the storyboard, which makes you think you suddenly got a table header).

The same view as before, but the UITableView is not the first subview anymore; the padding disappears.

The same view as before, but the UITableView is not the first subview anymore; the padding disappears.

Things shouldn’t be like this. Sure, there is some obscure documentation saying “Hey, if your Table View is the first subview of a view, it will magically get a padding on the top”, but that is a total bullshit. What if I, somehow, want to keep some logical order that requires an element just below the navigation bar but my table view should still get the padding? What if I need a bigger padding, then?

This thing should never be magical. It should be a flag, a value, even a freaking constraint, but not a damn magical positional setting which is not obvious at first glance.

Seriously Apple, this is the kind of bullshit that ruins our relationship…

The multiple faces of nothing

[… or “C, variants and the NULL”]

In C, you have a way to represent nothing. It’s NULL (all caps). NULL points to nowhere and it’s defined as “0”. Why would someone use it? Well, if you have a list and some of the elements aren’t valid, you make them NULL. Since NULL is not a valid pointer, your application will crash if you try to access it. The whole point of NULL is to provide a way to represent the nothing. There is also a nothing type “void”, which you can define anything statically, but you can make it a point of it. Since all pointers have the same size, a “void pointer” is, basically, a pointer to anything.

Also, C have the idea of “nul-terminated strings” (yes, with just one “l”.) the “nul” character is represented by “\0”, which, in practical terms, is a space of memory with the size of a “char” with the value 0 on it.

When going down to the very bits of NULL and nul, they go almost the same, except for their size.

C++ was build on top of C, but if defined NULL as a pointer pointing to the byte 0. It’s almost the same thing as the C NULL but, because it’s a pointer, it doesn’t need to be converted when you’re using a CPU which have a different size for “int”s and pointers (usually, pointers are “long int”s or even more, if your CPU have more than 64 bits.)

Objective-C is a variant of C adding support for objects in a different way and the biggest “user” of Objective-C is Apple. The Apple version of Objective-C provides some basic types like lists. But, because you can’t leave an empty space in the list (which I think it similar to the way we deal with nul-terminated string), they created a NSNull object, which is a valid object, but it represents the null (which, by the way, are called “nil” in Objective-C.) It’s not an invalid memory address, as it points to a real object. The NSNull object provides just one method, “null” which returns a “nil” pointer (are you confused already?)

Now, the fun part: Most list (dictionaries actually, but the process is almost the same) operations, when you try to access an object that doesn’t exist, returns nil. But remember that the only way to leave an empty spot in a list is adding a NSNull object. So, to be really sure that something is not there, you need to check if the result is “nil” or “not an [NSNull null]”.

That’s too much stuff for nothing…