[libobjc] May I tweak objc-api.h?
Kaelin Colclasure
kaelin@acm.org
Sat Feb 7 01:05:00 GMT 2004
On Feb 6, 2004, at 2:19 PM, Andrew Pinski wrote:
> On Feb 6, 2004, at 14:14, Ziemowit Laski wrote:
>
>>
>> On 6 Feb, 2004, at 14.07, Ziemowit Laski wrote:
>>
>>>
>>> On 6 Feb, 2004, at 14.02, Alexander Malmberg wrote:
>>>
>>>> Ziemowit Laski wrote:
>>>>> typedef struct objc_super {
>>>>> id self; /* Id of the object
>>>>> sending
>>>>> the message. */
>>>>> Class class; /* Object's super
>>>>> class.
>>>>> */
>>>>> } Super, *Super_t;
>>>> [snip]
>>>>> So, do you think it would be OK to rename 'class' above to, say,
>>>>> 'super_class'?
>>>>
>>>> This field is used in GNUstep. What do you propose that code should
>>>> do
>>>> to work with both versions? Change the name only if __cplusplus is
>>>> defined?
>>>
>>> Change the name unconditionally... please? :-)
>>
>> Of course, this only applies to stuff in headers that may get pulled
>> into
>> a C++/ObjC++ translation unit. I just noticed that GNU libobjc has
>> local
>> objects named 'class' in its .c and .m files, which is fine.
>
>
> But the structs are used in GNUStep and which cannot change just
> support one version of
> gcc. They have to support multiple versions of gcc. I rescind my ok
> on this. Knowing that
> programs will brake. Also changing it conditional on __cplusplus is
> okay with me as it is
> okay with Alex.
Hey, we're all supposed to be OO thinkers: How about we introduce an
accessor macro for this field, called say OBJC_SUPER_CLASS. Then we're
nicely abstracted even if in some future permutation of the runtime the
superclass isn't a member of this struct at all... :-) (The definition
of this macro would of course be conditional on the compiler / runtime
/ whatever version.)
#define OBJC_SUPER_CLASS(s) ((s)->super_class)
-- Kaelin
> Thanks,
> Andrew Pinski
> _______________________________________________
> objc-language mailing list | objc-language@lists.apple.com
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/objc-language
> Do not post admin requests to the list. They will be ignored.
More information about the Gcc
mailing list