Disparate types for the same value

I noticed that the "contents" property of SCNMaterialProperty can be any of fivesix things:

  • NSColor
  • NSImage
  • CALayer
  • CGColorRef
  • CGImageRef
  • [Update: Michael Tsai points out that it can also be an NSArray of six images.]

The three classes — NSColor, NSImage, and CALayer — are about as unrelated as you can get within the Cocoa class hierarchy. Their only common ancestor is NSObject. It's true they all implement NSCoding, and two of them implement NSCopying, but these are such common, generic protocols they hardly count as relating the three classes in a meaningful way.

The two CG pointer types — CGColorRef and CGImageRef — are not toll-free bridged to any of the classes, although they are C-based counterparts to NSColor and NSImage.

I wonder if this property sets a record for the greatest number of disparate, specific types a value is allowed to have in Cocoa. I'm talking about formal Objective-C types, disregarding semantics. Offhand I can't think of an example with more than two.

For example, CALayer itself has a "contents" property which can be either a CGImageRef or, as of Mac OS 10.6, an NSImage. Another example is buttons and cells, which at least unofficially allow NSAttributedString for their titles even though the API specifies NSString. (I don't know if this is officially documented.) Bear in mind that NSString and NSAttributedString are not related by inheritance.

Note that in all the examples above, there is only one conceptual "type" for the value in question, whether it's "graphical contents of a rectangle" or simply "a string".

House = Holmes + Jobs

Sometimes the obvious takes a while to dawn on me. When I started watching the TV show "House" I didn't catch on right away that Dr. House is kind of like Sherlock Holmes. For example, he often knows things about people he's just met that seem impossible until he explains them, whereupon they seem elementary. And every episode is structured as a detective story, with Dr. House as the genius detective. Even when I noticed these similarities, I didn't realize how much inspiration "House" takes from Holmes until I looked it up on Wikipedia.

I suspect I'm being slow on the uptake again, but the other day it occurred to me that House has a lot in common with another famous genius: Steve Jobs.

Consider:

Dr. House has a famously abusive managerial style that takes a heavy emotional toll on his subordinates. He's exquisitely attuned to people's weaknesses. He plays hurtful mind games. He pits team members against each other. He barges into rooms and insults people to their faces. [1]

At the same time, House's team is extremely loyal. They are drawn to him by his brilliance and charisma, and by the very fact that he pushes them hard. They accomplish great things with him that they wouldn't be able to anywhere else. House and his team accomplish the impossible, again and again.

One of House's talents is his ability to hire other talented people. He is extremely selective about who he will work with. As self-centered as he is, he would be the first to admit he is not a solo act. He constantly needs ideas from the team to fuel his own brilliance, even as he shoots down those ideas for being "moronic".

House is also selective about the projects he will work on. He will reject all "boring" proposals, and even some interesting ones, to focus on a project that he feels has some special quality. And then he will obsess over that project until he gets it right.

House can be wrong. In fact, he's wrong all the time; that's why the show is an hour long instead of fifteen minutes. When he's wrong he doesn't dwell on trying to prove he was actually right. He simply moves on and ignores any apparent contradiction with what he said before.

All of the above, and more, was true about Steve Jobs.

It seems to me there must be some conscious homage being paid by the creators of "House". It isn't just the Apple products all over the place or the one actual mention of Steve Jobs [2]. It seems to me there is Steve-ness at the show's very core. I can easily picture Hugh Laurie playing basically the same character he plays now, but with Cook, Schiller, Ive, and Forstall around the table instead of Chase, Taub, 13, and Foreman.

Heck, House shows up for work every day in jeans and running shoes. How much more "Steve" can you get?


[1] Regarding the abusive managerial style, I don't know if Jobs behaved quite as badly when he returned to Apple — indications are that he became a much nicer human being — but certainly the stories told about his early days at Apple and at NeXT are House-like.

[2] "Either that costs more than 25 bucks, or I'm seriously starting to doubt Steve Jobs' business strategy." (Episode 410, "It's a Wonderful Lie")

Scene Kit sample code

I just found out from Peter Hosey that sample code for Scene Kit is publicly available. There are three example projects:

  • Scene Kit Document Viewer
    • Shows basic features of SCNView.
    • Demonstrates hit testing. When you click on an object in the scene, the object is highlighted with a pulsating blue glow.
    • Demonstrates SCNView's built-in ability to pan, zoom, and rotate the scene in response to dragging the mouse.
    • Subclass of SCNView allows you to drag and drop an arbitrary .dae file into the scene view.
    • This is the project I referred to in my earlier post about redistributing Apple's sample code. This public version of the project is different in some minor but noticeable ways from the version I mentioned, which is behind a developer login.
  • Scene Kit Animations
    • Shows how to apply different animations to a scene.
    • Displays a row of buttons for selecting which animation to apply. I found that these buttons were hidden behind the scene view, and I had to rearrange things in the nib to make the buttons visible. I've reported this as rdar://12082268.
  • Scene Kit Material Editor
    • Shows how to fiddle with materials.
    • Provides a UI for tweaking attributes of materials and applying the materials to different shapes.
    • Also shows how to create simple 3D shapes programmatically — something I happened to be wondering about.

These projects all use modern Xcode stuff like ARC, collection literals, and (in two of the three) Auto Layout. Note that Scene Kit requires Mountain Lion.

As of this moment, Googling for "scene kit sample code site:developer.apple.com" still doesn't find these examples, which I find odd, since they've been available for a good ten days. The Scene Kit API docs don't point to the examples yet, but this is less surprising; I'm sure the docs will be updated in good time.

A quick way to find these examples is by going to the Mac Developer Library and entering "scene kit sample code" in the search field next to where it says "Documents" (not the field at the top right corner of the page). Using "sample code" in the search terms is a good way in general to find example projects.

Scene Kit sample code

Redistributing Apple's sample code

In the example source code that Apple gives to developers, they put licensing terms at the beginning of every file. As I read them, the terms essentially say: "You may redistribute this file without modification, but only if you leave these licensing terms in the file."

Isn't that a tautology? If I share the file without modification, then the licensing terms are already in the file. If I remove the licensing terms from the file, then it's no longer "without modification", and I am then free to share the file sans licensing terms. That's what I would naively think. Does the law include a rule of some kind to avoid this circularity?

Here's the language as it appears in every source file (excerpted, emphasis added):

In consideration of your agreement to abide by the following terms, and subject to these terms, Apple grants you a personal, non-exclusive license, under Apple's copyrights in this original Apple software (the "Apple Software"), to use, reproduce, modify and redistribute the Apple Software, with or without modifications, in source and/or binary forms; provided that if you redistribute the Apple Software in its entirety and without modifications, you must retain this notice and the following text and disclaimers in all such redistributions of the Apple Software.

Here's the reason I ask. I've been looking at a particular Apple example, and I felt compelled to fiddle with it. I applied my coding style, edited the comments, renamed things (including the project itself), added a delegate protocol, and fiddled with the UI. I feel the result is better than the original; maybe not hugely, but enough that I want to make the modified code publicly available.

I did this once before with an ancient example project called "Moriarity". At that time I removed the duplicated licensing terms from all the source files and put them in an accompanying file called LICENSE.txt. (Come to think of it, the legalese above makes more sense when the licensing terms are in their own file.) Now I'm wondering if that was really necessary. If not, then I'd rather not include a pointless license file with the project. Or rather, I'd rather include my licensing terms, which are that you're free to use my changes however you want, with or without attribution. Of course, I'd mention that the code is derived from an Apple example.

There are a couple of other issues that make me hesitate. For one thing, this is one of the example projects from WWDC, which means you need a developer login to get the original version from Apple. I'm not too worried about this, because this example is Mac-only, and unlike the iOS 6 SDK, the 10.8 SDK is now public. [Update: This example project is now public, and actually had been for a few days already when I wrote this post. It's the "Scene Kit Document Viewer" project I mention here.]

The other issue is that the example project includes artwork — a 3D model in a .dae file — that clearly belongs to Apple. I'd like to use this model, but I suppose if I had to I could find a public domain one to replace it with.

I'm probably worrying way too much about this, especially given how tiny the code in question is. I'm going to go out on a limb and guess that Apple has bigger legal fish to fry regarding people copying stuff. I should probably go ahead and publish my version of the code, and just decide: either include Apple's licensing terms just in case, or leave them out on the forgiveness-rather-than-permission principle. What's Apple going to do, get me in trouble for writing the exact code they advise us to write?