[nupark2]

When you remove the C bits, Objective-C and Ruby use the same type system, conceptually speaking. They are both descendant from Smalltalk; the main feature differences really come down to the syntax alone.

Objective-C is typed -- not just the C part, but the 'Objective' part too. You can cast around type system, but it's there.

The new compiler even uses inference of those types in order to implement ARC.

Especially given the amount of effort Apple has been putting into MacRuby.

Not Apple, just a few people that also work for Apple.

[skidooer]

The type system exists, but when working with the Objective half of the language, it is mostly meaningless, at least from a developer's point of view. With the C parts removed, you could replace every type definition with id and your program would run just fine.

The article says that MacRuby is bundled with Lion as a private framework. Surely they wouldn't bundle it if they weren't using it? And being a private framework, it is not there for the benefit of third-party developers.

[nupark2]

Objective-C is typed, and that's considered (by Apple, and most developers) as a feature, not just a legacy inheritance from C.

[jonhohle]

Objective-C types are optional and the language is dynamic, and that's considered (by Apple and most Objective-C developers) a feature.

    id something = nil;
    [something countForObject: nil];

Completely valid, won't crash your program, and only enough type information to satisfy the compiler (but largely meaningless for anything but the most basic static analysis). The only requirement for the above to compile is that countForObject: is a selector defined somewhere in the include path for the file. Even that is a relatively soft requirement since you can pass arbitrary selectors to any object.

And none of this has anything to do with ARC, as far as I can tell.

There was a first class language on Mac OS X which was fully statically typed. It was deprecated with Leopard and never introduced on iOS. The dual nature of Objective-C is one of its attractive properties.

[nupark2]

Most of what you just said is simply not true. Without the method types, the compiler will print a warning, infer the wrong ABI and generate the wrong code. If am ambigious match ia made, the wrong code will be generated. What you just wrote may work, but only because the compiler works to match against defined methods types, and even then it can and will get it wrong.

The support for 'id' is only intended to serve as a mechanism to get around the lack of parameterized types, and as part of ARC, the compiler does now infer the types for alloc/init.

[jonhohle]

> Without the method types, the compiler will print a warning, infer the wrong ABI and generate the wrong code.

Did you even try my example? No compiler warnings are generated (nor should the be). What do you mean by defined method types? It is simply looking for any selector which matches on any class because there is not enough statically available information to know any different. Messages are always passed dynamically.

Are we talking about Objective-C? Are you familiar with NSInvocation? Or performSelector:, performSelector:withObject:, performSelector:withObject:withObject:? Or NSNotificationCenter's addObserver:selector:name:object:? This is all done at runtime. No special type information is available to the compiler when using these. Objective-C messagse are always sent dynamically, so the only ABI concerns are how the stack is prepared, and not the interface of the class of an object. You can define methods and swap them out at runtime, this feature would be useless if everything had to be known at compile time.

ARC needs to know that the types of Objective-C objects, id still works fine, beyond that it needs to know no other type information from what I can tell.

It seems we are talking past each other. Objective-C is not like C++, though. All methods are virtual, always. The runtime goes through great pains to make that efficient and still allow complete dynamism. This is orthogonal from ARC.

[nupark2]

> Did you even try my example? No compiler warnings are generated (nor should the be).

Only because it managed to match on a defined method type. If a class declaration hadn't been found at compile time with the given declared method, it would have issued a warning.

If the match was ambiguous and the types incorrect, it would have emitted incorrect code, and possibly a warning (or always, with -Wstrict-selector-match).

> What do you mean by defined method types? It is simply looking for any selector which matches on any class because there is not enough statically available information to know any different.

By 'defined method types', I mean methods declared on visible classes that match the given selector.

If it matches on the wrong one, the wrong dispatch function and/or the wrong function call epilogue will be emitted.

Method calls are ABSOLUTELY NOT ABI identical for all possible types. I can't possibly emphasize this enough.

For example:

  - (void) performWithObject: (NSObject *) object;

  - (void) performWithObject: (NSObject *) firstObj, ...;

The instructions emitted for a vararg dispatch ARE NOT the same as the non-vararg dispatch on all platforms, and incorrect method selection will result in undefined behavior on dispatch.

> Are you familiar with NSInvocation? Or performSelector:, performSelector:withObject:, performSelector:withObject:withObject:? Or NSNotificationCenter's addObserver:selector:name:object:? This is all done at runtime.

> No special type information is available to the compiler when using these.

Yes, it is. Methods have associated type encodings that describe the return and argument types, and that's used to perform runtime dispatch with NSInvocation. This is why NSInvocation is so slow -- similar to libffi, it must evaluate the types and construct the call frame at runtime. It does this by evaluating the type data associated with method implementations by the compiler.

Methods such as performSelector rely on specific type conventions (such as void return, optional single object argument) and will fail if used with targets that do not match the expected convention.