Re: Refactoring a #define definition
Re: Refactoring a #define definition
- Subject: Re: Refactoring a #define definition
- From: Carl Hoefs <email@hidden>
- Date: Sat, 25 Jul 2015 10:37:50 -0700
> On Jun 25, 2015, at 3:04 AM, Dave <email@hidden> wrote:
>
>
>> On 24 Jun 2015, at 18:52, Carl Hoefs <email@hidden> wrote:
>>>
>>> Or better still, disable the “Refactor Menu Item” if something is selected that it doesn’t handle, seems pointless (and potentially dangerous) to me to allow the user to select something just to tell them (in a round-about manner) that it can’t handle what they have selected.
>>
>> The real question is why is it impossible for Xcode to refactor a #define?
>> -Carl
>
> It depends on what you mean by “refactor” it could globally replace it (behind the scenes), but an #define is handled differently from (say) a property or a method name. For these types of symbol it actually looks up the symbols in the compiler data structures rather than blindly looking at the source code - which is why it doesn’t always work.
>
> For instance if you had two classes that both define a property called “fred”:
>
> @interface ClassA
>
> @property (nonatomic,retain) NSString* fred;
>
> @end
>
>
> @interface ClassB
>
> @property (nonatomic,retain) NSString* fred;
>
> @end
>
> If you refactor “fred” in ClassA, it doesn’t (or shouldn’t) change ClassB whereas a Global Replace would change it everywhere.
But that's not a #define. Effectively, what the compiler does with a #define _is_ a global replace. So I don't see the issue that Xcode has in doing it.
-Carl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden