Not sure what other people's opinions are of this, but the OperationS Subsection of the S.S.S. with a Capital S on the end seems like a typo. I understand that often times people will add their own twist on things, resulting in slang, trademarks, and other fun word play, but I feel in this case that the added capital S does not do that. Instead it just comes across as an accident mistake, like calling TAK the Tartary Army Coorps or something. As such I'd like to encourage Corvus Belli to consider dropping the capital S, and just using the name without it.
Where do you see OperationS Subsection? Usually it's either "Operations Subsection", as in army: Or it is OperantionS as a sort-of contraction (S is capitalised to make it work double for Subsection).
The Wiki. When I asked IJW about it, since it appeared to be a typo to me he said that it was correct with the capital S on the end. "OperationS Subsection of the S.S.S." http://infinitythewiki.com/en/List_of_Fireteams#OperationS_Subsection_of_the_S.S.S. It also seems to be causing some confusion, since as you point out Army6 would be incorrect. Also it's in Third Offensive.
Hm. That is quite silly indeed. But what do I know? ¯\_(ツ)_/¯ CB does follow no principles when determining unit names.
Errr... I don't think that's true. Check the document you just shown: if "Operations" is followed by "Subsection", it's with lowercase "s". If it is without "Subsection", then it is with uppercase "S". 8 examples, 2 are "Operations Subsection", 6 are "OperationS".
Pretty clear that OperationS is an abbreviation for "Operation Subsection". Therefore OperationS Subsection would be redundant.
MicroSoft also use that bastardised aberration of language (mid-word capitalisation) as do a number of other corporate structures. So it's not like CB is alone in this. You can either get over it or have an unending conniption that will result in a stroke at some later time. :D
As you probably know, this is a programming convention called camel case. I agree that any number of corporations and our own favourite game designers abuse the hell out of it, so you may be amused by one of the dubious joys of writing Apple software... [Disclaimer: persons who dislike Apple for whatever religious reasons may wish to skip this post, thank you]. Whatever you think about Apple's rise to dominance, it all began when NeXT took over Apple Apple bought NeXT in 1999, because the company that cared so much about design also finally had the engineering tools to make their designs useful and meaningful. This was the foundation of their success, because the NeXT team had managed to crack a non-trivial problem called object-relational mapping. This was the barrier to developing true enterprise-level software with object-orientated programming languages and relational database tables. By definition, you can't fix a non-trivial problem, you can only manage it. And the NeXT team not only figured out how to manage it, but also provided an elegant tool to help programmers do so in the early Nineties. Interestingly, the only people who cared about this at the time, were investment banks, large corporations like Motorola, Dell and Toyota, and... the CIA. Anti-Apple types who're still with me might draw their own conclusions about that one. Probably correctly. Their solution was the legendary EOM - the Enterprise Object Modeller. Nearly a decade before the open source community managed a similar solution, and nearly two decades before it was anywhere near as usable. When it was released, programmers marvelled at two things. The elegant genius of their solution, and the unbelievable method names they all had to employ to apply it! These are the very names that solved that object-relational mapping problem. Code: void addObjectToBothSidesOfRelationshipWithKey(EORelationshipManipulation eo, String key) void removeObjectFromBothSidesOfRelationshipWithKey(EORelationshipManipulation eo, String key) Removes the enterprise object EO from the receiver's relationship, which is identified by key, and also removes the receiver from the enterprise object eo's inverse relationship if there is one. Source: legacy documentation, here Note that addObjectToBothSidesOfRelationshipWithKey has no explanation, because it literally adds a software object to both sides of an SQL database relationship (an SQL 'join' mapped as a EORelationshipManipulation) with the name (key) you give it. The name is on the tin and programmers love that stuff. What do you mean you don't like camel case?
Examples? If you're talking about camel case that's been gone for a while, and involves capitalizing new words that would typically be separated by spaces, so it's a very different thing.
@RogueJello if you would be from Germany, you would know that S.S. would be a terrible abbreviation cause of this
You lost me at camel case? I was assuming a box with neat dividers to keep your bactrians away from your dromedaries ...
Yeah, I’ve been struggling with all those s’s, and dont suppose Corvus Belli were unaware of the Schutzstaffel connotations that @Ben Kenobi pointed out either. Since the ‘OperationS’ section is not a particularly compelling piece of lore, but pronounced ‘Operation Ess’ does fix the pronunciation difficulties, perhaps we can presume that was the purpose of the word?
I hate the name, and i hate the full name. Oss it is for me, it's evocative and short enough. Envoyé de mon LG-H815 en utilisant Tapatalk
I might be the odd one as i like both OSS and OperationS, then again i already went though a similar thing years ago already.
