Since nobody uses Obj-C without Xcode, you actually never need to type out a long method name. Typically you'd just write "sha", Xcode will autocomplete the method, and you press Tab to fill out all those parameters. Seeing them all at once as part of the method name is pretty convenient.
I'm not saying that the method name in your example makes any sense, it's definitely insanely long... But the Apple API mentioned in the original post is OK in my books because it's a rarely used initializer for a low-level object. It essentially wraps a raw C pointer into an object, so of course it needs all that metadata about what the pointer is! Putting the same data in a struct wouldn't save any typing.
Sometimes I write it in Sublime. Although even then, I sometimes just write the method in Xcode to get the autocomplete then copy paste it, or just open the non-xcode-project file in xcode.
Well then we can just add "if you have to abbreviate your function name and arguments for the common form to fit in a tweet, you're probably doing it wrong".
> "if you have to abbreviate your function name and arguments for the common form to fit in a tweet, you're probably doing it wrong".
There go all my Unix commands! (OK, that is an uncharitable interpretation—changing `mv` to `move` wouldn't overflow a tweet—but it does indicate, I think, that it's not always obvious when an abbreviation is reasonable.)
Those abbreviation decisions were made in the early 1970's. How does that indicate the non-obviousness of deciding when it is or is not appropriate to use abbreviations today?
I was writing from the point of view of someone who finds Unix abbreviations perfectly acceptable (as compared to my comically abrogated SmallTalk / Objective-C (I don't even know which) invocation above (https://news.ycombinator.com/item?id=10990803), which I'd say is clearly not acceptable). Certainly, my argument will not be convincing to someone who doesn't share that point of view.
Unix is incredibly guilty of this. Everything would be so much easier to learn if mv was generally aliased to move and all code examples used the long version.
> Everything would be so much easier to learn if mv was generally aliased to move and all code examples used the long version.
I dunno; Tim Berners-Lee has said that his single biggest mistake was including two slashes in URLs (as in http://news.ycombinator.com, as opposed to http:/news.ycombinator.com). (I can't find any better citation for this than http://www.plughitzlive.com/theupstream/298-creator-of-the-w..., unfortunately.) I think that one shouldn't underestimate the apparently negligible impact of an extra character or two, if there will be millions of people typing those extra characters potentially many times a day, over the course of decades or centuries.
(Actually, now that I read your post more carefully, you say that `mv` should be aliased to `move`, meaning, I assume, that `mv` would also be available. I am still unsure about that, because most people would never bother to learn the short version—witness how many people don't know keyboard shortcuts for their most commonly used programmes—but I guess the experts would, and that, perhaps, is enough.)
He wasn't even saying that the // should be a single /, he was saying that the : at the end of the protocol identifier is already sufficient. He wanted something more like:
Don't listen to me—I don't know anything about good API design. (That's not sarcasm or modesty, but the simple truth.) However, if the self-diagnosed biggest mistake of Tim Berners-Lee's life was to add a single extra character to a commonly typed string, then surely one has to consider that the addition of two extra characters could eventually also be judged a mistake?
From my point of view, he wasn't saying it because it's an extra character, but because http://news.ycombinator.com is more cryptic and harder to understand than http:news.ycombinator.com.
That fits into my belief that more readable (move instead of mv) is better.
In iOS 9, there currently seem to be 45 methods whose selector alone is longer than 140 characters. But how many of those are actually supposed to be used is another question ;)
I would guess that this method was created by a code generator, starting from a data structure with all of those fields.
More generally, a long initializer (or class method that returns an autoreleased object) is a fairly common pattern in Objective-C because it provides a common piece of code that all other initializers can call. There is usually some more obvious and convenient choice available, to avoid calling the horrible method directly.
Windows is known for having some rather long API names, such as RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext or EapHostPeerQueryUIBlobFromInteractiveUIInputFields. More examples at:
