Property syntax erroneously converted to method syntax (ie. dots to square brackets) Follow
AppCode automatically replaces things like
but I don't want it to. Is there any way to turn this behaviour off?
I assume it's because frame isn't explicity declared as a property of NSView - just the getter and setter are declared - but the dot syntax is still legal and it's neater in my opinion.
This is particularly inconvenient when setting the property. You want to type
self.view.frame = someRect;
but you end up with
[self.view frame] = someRect;
which obviously isn't going to work. I'd really just prefer to be able to turn this conversion off altogether, but I can't find a setting for it. Am I missing something?
Please sign in to leave a comment.
OK, I've just fixed that. It will only transform to a method call syntax if the method chosen has parameters or completion lookup is terminated by chosing ']' character, clearly indicating method call was expected.
Fantastic - thanks Maxim.
AppCode is shaping up into a great piece of work. I'm an Idea user (I have a couple of Java/Objective C hybrid apps) and to me XCode has always seemed sadly lacking; the arrival of AppCode is very welcome. You really are putting Apple to shame!
There seems to be a pretty serious bug in the RC which means that method completion by . isn't being expanded out properly, e.g.:
NSObject *obj = [[NSObject alloc] init];
If I execute code completion here, I see autocomplete in the list, but if I select it, I get :
Just wondered if this had been introduced by this fix? Or should I submit a seperate issue?
Whatever it seems pretty important to get sorted before release!
If you type
ie. a space not a dot, you'll get what you want. You don't even need the opening square bracket.
It seems reasonable for AppCode to expect you to differentiate between whether you want property syntax or method invocation syntax.
Yes I'm aware of the completion with space, but appCode also used to work with dot too. In fact it does if the method call has a parameter, this problem has only started happening with zero param methods.
I imagine it might well be the above change that has caused the change in functionality; no doubt one of the developers will be able to tell us more.
But personally I wouldn't consider loss of this functionality a bug - it seems weird for dot syntax to work at all for something that's clearly method invocation not property use.
I realise dots-for-methods has been working, I'm just not convinced that it should - especially since it muddies that waters when it comes to actual property use. Objective C isn't Java (or whatever), after all.
Well, it seems we need to tune the heuristics again. Would it look right if we convert to method call syntax any calls except those, that have corresponding setters? Your NSView.frame case will be covered.
Well if it's a big deal to sort this or causes inconsistency I wouldn't mind having to move over to using space instead of dot I guess, I was just flagging this as an issue as it had worked a certain way thus far.
However, AppCode does seem to know I'm selecting a method - the method icon is shown in the completion popup - so it seems to have the information it needs to make the correct choice.
Better perhaps to be more conservative about the conversion:
- convert to method syntax if there is no zero-parameter method (or property declaration) but there is a one+ parameter method
- convert to method syntax if there is a zero-parameter method returning void
the idea being to convert only if it is clear that property syntax would be wrong and therefore not intended.
The absence of a setter isn't a very good indicator, eg. you want to be able to write:
NSLog(@"my cat has %d legs", cat.numberOfLegs);
for either of the following declarations:
@interface Cat : NSObject
@property (readonly) int numberOfLegs;
@interface Cat : NSObject
- (int) numberOfLegs;
You wouldn't expect to have a setter in this situation, but property syntax is still valid.
You might wonder why we don't just make @property declarations and save the confusion. The answer is that in our own code, we probably do - it's Apple's API code that doesn't (presumably for historical reasons) and we don't want to lose property-style calls there.