Why not start convenience constructors with "with"?

Question

One of the things I like most about Cocoa is the readability factor.

One of the things that annoys me the most is the convention of convenience constructors to force repetition.

Here's an example:

[NSString stringWithString:s]

[NSNumber numberWithDouble:d]

[NSValue valueWithInt:i]

[NSDictionary dictionaryWithObjectsAndKeys:<blah>]

etc.

Why doesn't the convention simply start convenience constructors with the word "with"? so then we would have:

[NSString withString:s]

[NSNumber withDouble:d]

[NSValue withInt:i]

[NSDictionary withObjectsAndKeys:<blah>]

etc.

It's a minor discussion point, but one I thought I would just throw out there and see if anyone with more clout than me can explain all the echos in my head.

Obviously, I'm not going to petition AAPL to re-write the appKit in favour of my suggestion, but are there any arguments against naming my own convenience constructors as such?

Of course I can use whatever conventions I want in my own code but I hate to swim upstream blindly.

Answer 1

There is actually a technical reason for it to be that way. If every shoelaceWithString:-type method were changed to just withString:, we would end up with a fearsomely huge number of classes with identically named methods and different signatures. This plays mean tricks on the compiler's static type checking and can cause it to throw up all sorts of annoying and unnecessary warnings.

There's also an aspect of Cocoa culture where developers like their code to be self-documenting. This means that method names indicate both what their arguments are and what they return. Apple's coding guidelines actually warn about methods with vague names, suggesting that adding words to the name to make it clear what a method does is preferable.

Answer 2

Because it's consistent.

There are methods like:

[NSDictionary dictionary]
[NSArray array]

Getting rid of everything up to with is obviously not an option here. Keeping these, but shortening others would introduce inconsistency in naming of convenience methods.

And convenience methods are consistent with init and initWith… methods.