Let me point out that the common-sense reading of that clause is straightforward. The word “originally” clearly implies that writing this:
UIView.SetAnimationTransition(UIViewAnimationTransition.FlipFromLeft, this.Superview, true);
and transforming it into:
[UIView beginAnimations: nil context:context];
[UIView setAnimationTransition: UIViewAnimationTransitionFlipFromLeft forView: [self superView] cache: YES];
[UIView setAnimationCurve: UIViewAnimationCurveEaseInOut];
[UIView setAnimationDuration: 1.0]
is forbidden. To take it to the extreme, can you imagine betting your company on convincing a jury that writing the first (which is C# and MonoTouch) and generating the second means it was “originally written in Objective C”? If so, you have some hard lessons about the legal system to learn.
I should point out that even though this code is clearly very similar, there are some slight differences, such as C#’s enumerated values UIViewAnimationTransition.FlipFromLeft as opposed to Objective C’s constant value UIViewAnimationTransitionFlipFromLeft. The . makes a difference in the parse tree and in the programmer’s mind — a small one, but a helpful one.
I should also point out that today MonoTouch does not generate the Objective C 2nd listing. It probably generates something like:
L_0001: ldstr ""
L_0006: call void Foo.UIView::BeginAnimations(string)
L_000d: ldsfld class Foo.UIView Foo.UIView::Superview
L_0013: call void Foo.UIView::SetAnimationTransition(valuetype Foo.UIViewAnimationTransition, class Foo.UIView, bool)
L_001a: call void Foo.UIView::SetAnimationCurve(valuetype Foo.UIViewAnimationCurve)
L_0020: ldc.r8 1
L_0029: call void Foo.UIView::SetAnimationDuration(float64)
which is “Common Intermediate Language.” The .NET Virtual Machine loads CIL files directly, while MonoTouch generates at compile time native code, which which is an exercise left for the interested student (and, while hardly trivial, is a mechanical process that can be reviewed for efficiency, improved, etc.). (The “nop”s, by the way, are for breakpoints and wouldn’t be generated in a release build).
Generating two levels of low-level code (C# -> CIL -> Native Code) may seem to be the source of inefficiencies, but generating for an intermediate assembly language is very common with modern compilers. Code generation may be a source of inefficiencies or it may be a place of optimization — that’s dependent on the skill of the compiler writers.
The reason why it’s absurd to forbid native code compilers but allow Objective C code generation is that there is no difference between generating assembly language and generating C. If you can write an IL->Native Code compiler, of course you can write a IL->C compiler. So were code generation legal, a potential strategy for other alternative language vendors would be to do FooLanguage -> Foo IL -> C (“OK, lawyers, as you can see, we are simply generating C code”) -> Apple Approved C Compiler -> Native. Kafka-esque absurdity, but perfectly cromulent. Indeed, I strongly suspect that all of the alternative language vendors are preparing just such a tactic as “Plan B” or “Plan C” in case Apple relents on the word “originally.”
The Double-Edged Sword
Why should Apple allow alternative code generation? They fear inefficiencies, they cannot control the efficiency of code generation, therefore it is logical to forbid code generation. Why is that unreasonable?
The reason is that if you forbid code generation, you forbid huge swaths of good programming techniques. Rather than go on about lex and yacc and report generators and screen managers, though, we have the delightful “The Elements” iPad app to make the point. Don’t take it from me that code generation is good, read the article:
Even the amazing animation synchronized to Tom Lehrer’s iconic song “The Elements”, which plays the first time you open the e-book, was generated entirely by a Mathematica program.