Re: Strange crash in __objc_resolve_class_links

[Richard Frith-Macdonald]

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

>> Incidentally, when most of the GNustep maintainers met at FOSDEM this year, 
>> we decided to ban the use of the '.' operator for property access within 
>> GNUstep ... it's pretty universally thought to encourage bad code by 
>> obscuring what's going on, and your example above is a case in point ... the 
>> '(void)r.plist;' would conventionally be thought of as a reference to an 
>> instance variable, and since the value is not used, many people would expect 
>> the compiler to simply optimise away that line of code completely.  You 
>> ought to use '(void) [r plist];' instead.
>> Similarly, 'r.errorMessage' obscures the fact that messaging is going on ... 
>> it ought to be [r errorMessage].
> 
> I respectfuly, but strongly disagree.
> 
> One of the reasons why I love ObjC is readability and clarity of intention. 
> Key thing here is the intention. Intention of "grabbing a property of an 
> object" as opposed to "getting a result of an operation" is clearly stated 
> with the dot syntax.

I don't want to get into a long discussion about this, but what you say here is 
clearly not the case:

Consider the '(void)r.plist;' in your own code ...
If the dot syntax says you are grabbing a property, then that line of code 
should have no effect (because you are grabbing the property and throwing it 
away), so the compiler ought to remove that line and generate a warning message.
What you are actually doing there is presumably writing code which depends upon 
your knowledge that you are actually executing the -plist method of the object.

Most people like ObjC's readability and clarity of intention ... and most of us 
think that the dot syntax tends to obscure that clarity.  If we thought it made 
things readable and clear we'd be in favour of it.

> Finally, for future projects and other decisions, I need to know:
> 
> Is the stance of GNUstep project that ObjC2.0 will, long term, be unsupported 
> in apps?

There's no position on what you do in your own apps ... you can use whatever 
you like.

I was simply making two points:
1. that we have no simple testcase to demonstrate your problem and it's hard 
for anyone to help without that ... the fragment of code tells us nothing since 
it calls other methods, and since memory may have been corrupted before it's 
even reached.
2. that avoiding the dot syntax would probably make your intentions clearer.