Re: Strange crash in __objc_resolve_class_links

[David Chisnall]

On 16 Feb 2011, at 10:53, Ivan Vučica wrote:

> Not using dot syntax because it "hides the fact that you are calling a 
> method" is pretty funny to me. It is easy to see if something is an object or 
> a pointer; dot syntax would clearly be invalid there unless one uses it to 
> access a property. To access ivar, those confused developers should anyway 
> know the -> operator is used. (And that is something I would ban nowadays, 
> except in highly performance sensitive code. Why should other classes be 
> aware of the internals of this particular class, or touch its ivars?)

The problem is not differentiating between ivar and property calls, it's 
differentiating between structure field access and property access.

One of the core points in the Objective-C philosophy is that there should be a 
direct correspondence between syntax and semantics.  New semantics should 
always involve new syntax, old syntax should not be used for new semantics.  
This is very important because it makes it easy to understand what a piece of 
code is doing, without having to reference lots of other pieces of code.  
Contrast this with C++, for example in this line:

doSomething();

In C++, this can be:

- A C function call.
- A static C++ member function (semantically equivalent to a C function)
- A non-virtual C++ member function, with this as a hidden parameter
- A virtual C++ member function, dynamically looked up depending on the type of 
the callee

In contrast, this line in Objective-C, the equivalents are:

doSomething();
[MyClass doSomething];
[self doSomething];

All of these are distinguishable without looking at any other code.  You can 
read this and immediately understand the semantics.  This is very important for 
readability.

Contrast this now with the dot syntax:

a.foo;

This can be:

- A structure member reference
- An Objective-C message send calling a synthesised method that access a 
property
- An Objective-C message send that calls a user-written method that may have 
complex side effects

This can be made much worse by things like:

a.foo++;

This is equivalent to:

[a setFoo: [a foo]+1];

But the syntax completely hides the fact that you're doing two method calls.  
It lets you write code that is very complex, but with this complexity 
completely hidden in the source.  This is particularly dangerous with atomic 
properties, because you'd intuitively assume that ++ on an atomic property is 
an atomic operation, but it isn't.

David

-- Sent from my Difference Engine