iOS Some help / explanation about a warning in xcode

[DennisBlah]

Im working on my project and Im getting some warnings which I cannot fix.
(I hate warnings and wanna get rid of it)

Its about the following functions I made:

+(BOOL)plistFound:(NSString *)fileName;
+(BOOL)copyPlist:(NSString*)fileName;
+(BOOL)removePlist:(NSString*)fileName;
+(NSMutableDictionary*)loadPlist:(NSString*)fileName;
+(void)insertArray: (NSString*)plistFile: (NSString*)insertKey: (NSMutableArray*)theArray;
+(void)insertValue: (NSString*)theFile: (NSString*)theKey: (NSString*)theValue;
+(BOOL)deleteFromList: (NSString*)plistFile: (NSString*)deleteKey;
+(BOOL)keyExists: (NSString*)plistFile: (NSString*)checkKey;

The warning I get is :
'plistFile' used as the name of the previous paramater rather than as part of the selector

and same one about 'theKey'

Why does this occur ? As in these paramaters are only used inside the functions... When renaming the parameters for every function so they are not the same, its still not working well.

Next of that, this is my .h file.
How can I make it so when I'm using these functions that the Xcode already tells me like

[plistMngr insertArray: (NSString*)plistFile: (NSString*)insertKey

So that I know later what the paramater should contain? Instead of that it tells me
insertArray: (NSString*): (NSString*)

 

[dantastic]

You need to add a wee bit more information to your method declaration.

As an example

+(BOOL)deleteFromList: (NSString*)plistFile: (NSString*)deleteKey;

should be written as

+(BOOL)deleteFromList:(NSString*)plistFile keyToDelete:(NSString*)deleteKey;

 

[Duncan C]

This line:

+(void)insertArray: (NSString*)plistFile: (NSString*)insertKey: (NSMutableArray*)theArray;

...has a colon that does not belong. ("plistFile:" should be "plistFile" with no colon after.) In fact, all of your methods that take more than 1 parameter have too many colons.

The syntax of an instance method declaration is something like this:

- (return_type) firstParamLabel: (firstParamType) firstParamVarName
secondParamLabel: (secondParamType) secondParamVarName;

The first bit after the return type does double duty as the name of the method as well as the label for the first parameter (if any.)

Note that there is no colon after the variable name ("firstParamVarName ") and before the label for the next parameter.

Im working on my project and Im getting some warnings which I cannot fix.
(I hate warnings and wanna get rid of it)

Its about the following functions I made:

+(BOOL)plistFound:(NSString *)fileName;
+(BOOL)copyPlist:(NSString*)fileName;
+(BOOL)removePlist:(NSString*)fileName;
+(NSMutableDictionary*)loadPlist:(NSString*)fileName;
+(void)insertArray: (NSString*)plistFile: (NSString*)insertKey: (NSMutableArray*)theArray;
+(void)insertValue: (NSString*)theFile: (NSString*)theKey: (NSString*)theValue;
+(BOOL)deleteFromList: (NSString*)plistFile: (NSString*)deleteKey;
+(BOOL)keyExists: (NSString*)plistFile: (NSString*)checkKey;

The warning I get is :
'plistFile' used as the name of the previous paramater rather than as part of the selector

and same one about 'theKey'

Why does this occur ? As in these paramaters are only used inside the functions... When renaming the parameters for every function so they are not the same, its still not working well.

Next of that, this is my .h file.
How can I make it so when I'm using these functions that the Xcode already tells me like

[plistMngr insertArray: (NSString*)plistFile: (NSString*)insertKey

So that I know later what the paramater should contain? Instead of that it tells me
insertArray: (NSString*): (NSString*)

 

[DennisBlah]

Wow this is amazing.
I didnt understoud very well how to build up the functions nice and tidy.

Thanks for all your replies, I now understand that I firts tell what the second third or fourth variable will be holding.

Like:

InsertArray:(NSString*)theFile keyToInsert:(NSString*)insertKey valueToInsert:(NSString)insertValue

So when I'm typing the function it will show me

insertArray:(NSString*) keyToInsert(NSString*) valueToInsert(NSString*)

still I think its a bit odd that you have to define it twice. Once for the 'explanation' xcode will show up, and once for the internal usage inside the function :-/

Ah well, its going great I lost all my warnings! Thanks again!

 

[dejo]

Like:

InsertArray:(NSString*)theFile keyToInsert:(NSString*)insertKey valueToInsert:(NSString)insertValue

So when I'm typing the function it will show me

insertArray:(NSString*) keyToInsert(NSString*) valueToInsert(NSString*)

Just be aware that Objective-C is case-sensitive and there is a difference between InsertArray: and insertArray:

still I think its a bit odd that you have to define it twice. Once for the 'explanation' xcode will show up, and once for the internal usage inside the function :-/

This is because Objective-C uses named-parameters, unlike some other languages (such as Java) that use unnamed-parameters. It makes using the method more self-documenting.

 

[ArtOfWarfare]

This is because Objective-C uses named-parameters, unlike some other languages (such as Java) that use unnamed-parameters. It makes using the method more self-documenting.

I disagree. Parameters are passed within the name of the function - that doesn't mean the parameters are named. Were the parameters named, like Python parameters can be, you'd be allowed to arrange the parameters in any order so long as you have the proper name= to the left of it. But yes, the practice of having parameters passed within the function improves the readability, as opposed to languages where functions are passed a list of parameters without any form of labeling at all.

It seems silly that you need to name the parameters twice in Objective-C. You described the use of the variable to the left of the colon and it's type to the right of the colon - why give it a name in a declaration? I understand the need in the definition.

 

[dejo]

Even Apple states, in their Programming with Objective-C guide:

Some programming languages allow function definitions with so-called named arguments ; it’s important to note that this is not the case in Objective-C. The order of the parameters in a method call must match the method declaration, and in fact the secondValue: portion of the method declaration is part of the name of the method:

someMethodWithFirstValue:secondValue:

This is one of the features that helps make Objective-C such a readable language, because the values passed by a method call are specified inline , next to the relevant portion of the method name...

So, yes, technically, Objective-C is not using named parameters / arguments. Some describe it as 'interleaving'. But, I feel this is starting to get into a more "philosophical" discussion on how Objective-C syntax works. Because they are not unnamed, to me, means they are named.

 

[chown33]

It seems silly that you need to name the parameters twice in Objective-C. You described the use of the variable to the left of the colon and it's type to the right of the colon - why give it a name in a declaration? I understand the need in the definition.

It's that way to make copy-and-paste easier during development. That is, you can copy the declaration, change the semicolon to a { ... } block, and you have a syntactically correct definition.

Compare and contrast with classical C, where declarations were quite different from definitions. Example declaration:

return_type funcname( param1, param2 );
   /* Note the absence of param typenames. */

Example definition:

return_type funcname( param1, param2 )
type1 param1;
type2 param2;
{
   ..code..
}

It wasn't necessary to put the param's type-declarations in order. This would also work:

return_type funcname( param1, param2 )
type2 param2;
type1 param1;
{
   ..code..
}

C still allows you to declare functions with typenames only in the arg list, rather than typename/paramname pairs. E.g.:

double pow( double, double );

This makes it harder to copy-and-paste declarations, so one generally finds this syntax only in system headers, or headers that are rarely modified. It's generally easier to write one's own headers with the function declarations identical to the start of the function definition.

 

[ArtOfWarfare]

It's that way to make copy-and-paste easier during development.

Were I making an IDE, I think I'd disable the copy function. The fact that C, Obj-C, and C++ encourage the use of copy and paste for something so common is... IDK, upsetting? When you copy a piece of code, you should have an alarm that whatever you're doing is probably wrong and you should probably refactor.

Header files are really just clutter, I think. They're extra files that crowd your sidebar and contain little that the implementation file lacks. Their only real defense is that you can distribute them with libraries without including your source code, but it seems to me that you should just include their generation in a build script if/when you choose to make a library or framework.

Your classical C declaration is interesting. It reminds me of Smalltalk - I can't say I recall ever seeing anything declared that way before.