[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange crash in __objc_resolve_class_links
From: |
David Chisnall |
Subject: |
Re: Strange crash in __objc_resolve_class_links |
Date: |
Wed, 16 Feb 2011 12:22:19 +0000 |
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
- Strange crash in __objc_resolve_class_links, Ivan Vučica, 2011/02/15
- Re: Strange crash in __objc_resolve_class_links, Jason Felice, 2011/02/15
- Re: Strange crash in __objc_resolve_class_links, Richard Frith-Macdonald, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, Ivan Vučica, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, Nicola Pero, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, Richard Frith-Macdonald, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links,
David Chisnall <=
- Re: Strange crash in __objc_resolve_class_links, Ivan Vučica, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, David Chisnall, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, Dr. H. Nikolaus Schaller, 2011/02/16
- Re: Strange crash in __objc_resolve_class_links, Ivan Vučica, 2011/02/16