gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFI]: getting objc to grok attributes ??


From: Nicola Pero
Subject: Re: [RFI]: getting objc to grok attributes ??
Date: Fri, 21 Jun 2002 11:57:44 +0100 (BST)

>  > [...]
>  > The reason is that, while in C you define a function and normally the
>  > function has a single implementation associated with it (so, if an
>  > argument is unused, it's suspicious that there might be a mismatch between
>  > the declaration and the implementation, and it's a good idea to warn), in
>  > ObjC is very common to define a method in a place and have many different
>  > implementations of the method in many different classes.  For example -
> 
> Yes, C++ (whose syntax I do know) is much the same.  In C++, one can
> omit function/method parameter names when they are unused and g++
> avoids warning in these cases.  E.g.
> 
>  > int foo (int a, int, char *)
>  > { return a; }
> 
> Here g++ will not warn about the unused 2nd and 3rd arguments.  I
> don't know objc syntax to suggest a similar mechanism.  (It may not be
> possible, if you can omit the type there's no argument placeholder?)

I thought about it (and talked with some friends), and I think this syntax
would cause confusion in certain cases.

Normally, an ObjC method is declared as follows -

 - (void) doThis: (NSString *)a
        withThat: (NSString *)b;

the selector for the method is @selector(doThis:withThat:).  The arguments
are `a' and `b'.

You can have methods without the fraction of the selector name before the
next :, as in 

 - (void) doThis: (NSString *)a
                : (NSString *)b;

the selector for the method is @selector(doThis::).  The arguments are
still `a' and `b'.  Some people like to write code in this way, as they
think that the variable names already give enough explanation of what the
variables are about, and don't like over-verbose methods.

And here is why I think the C++ syntax would be a problem - I just tested,
and the compiler already accepts

 - (void)doThis:(NSString*)
              a:(NSString*)b;

and interprets it exactly as before - the selector is @selector(doThis::),
the first argument is `a', the second argument is `b'.

I don't write code in this way, but I can quite see that there might well
be people coding [unreadable IMO] stuff like -

 - (void)doThis:(NSString*)a:(NSString*)b;

you see that stuff from time to time on the net.


But if you are allowed to omit argument names, then that same declaration
might actually be read as 

@selector(doThis:a:)

with the name of the first argument having been omitted, and the second
argument being `b'.

This would likely cause confusion in the parser ... 


I also think, even if we introduce special rules to remove the confusion
(not sure which ones though), it would make parsing more difficult - it's
quite common to have custom Objective-C semi-parsers in the user code (eg,
to extract all classes or all methods from a header file, or perform other
types of activities in support of developing tools).  Keeping the
Objective-C syntax very simple helps those parsers.  I think allowing to
omit the argument name might make the syntax more complex to parse.


>  > Depending on the semantics of __attribute__ ((__unused__)) [does it mark
>  > the argument as being possibly unused in that method implementation, or is
>  > it a system-wide declaration that in all implementations of methods with
>  > that name/signature the argument could be unused ?],
> 
> In frontends where its currently implemented, attributes on parameters
> are specific to the exact function or method where one uses it.  I
> would expect that if we extend objc to allow it we would follow this
> convention.

Ok - yes would make sense


>  > So, maybe (from an ObjC user point of view) we should better disable the
>  > warnings for unused method arguments, unless some -Wxxx option is included
>  > to cause them (my bet is nobody will ever want to use that option, but
>  > anyway).
> 
> 
> If that's the consensus among objc developers fine, but I'm not sure I
> like it and its beyond what I would be interested in implementing.
> Its too blunt, I prefer a clean way of specifying which unused
> identifiers are ignorable and warn about anything else.
> 
> Can you perhaps suggest something based on the C++ example I gave?

My feeling is that the C++ syntax would not work, as explained above, and
I don't like the idea of changing the ObjC syntax, particularly if that
requires introducing exceptional cases which complicate it.

Said that, I wouldn't say yet that the consensus is to remove the warnings
:-) it's my opinion and of a few of my gnustep friends - we probably want
to get more feedback from other users (Stan might have access to quite
another large pool of experienced users in the form of the Apple ObjC
developers) to get a better understanding (maybe someone else can suggest
a great, different - or improved -, solution).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]