If you stop to think about it, you'll see that an interface really isn't semantically much different from an abstract class:
- Both have methods and/or properties (behaviour);
- Neither should have non-private fields (data);
- Neither can be instantiated directly;
- Deriving from one means implementing any abstract methods it has, unless the derived type is also abstract.
In fact, the most important distinctions between classes and interfaces are:
- Interfaces cannot have private data;
- Interface members cannot have access modifiers (all members are "public");
- A class can implement multiple interfaces (as opposed to generally being able to inherit from only one base class).
Since the only particularly meaningful distinctions between classes and interfaces revolve around (a) private data and (b) type hierarchy - neither of which make the slightest bit of difference to a caller - it's generally not necessary to know if a type is an interface or a class. You certainly don't need the visual indication.
However, there are certain corner cases to be aware of. In particular, if you're using reflection, interception, dynamic proxies/mixins, bytecode weaving, code generation, or anything that involves messing directly with the environment's typing system or code itself - then it's very helpful and sometimes necessary to know right off the bat whether you're dealing with an interface or a class. You clearly don't want your code to mysteriously fail because you tried to add a class, rather than an interface, as a mixin.
For typical, vanilla, run-of-the-mill business logic code, though, the distinctions between abstract classes and interfaces do not need to be advertised because they'll never come into play.
All of this being said, I tend to prefix my C# interfaces with I anyway because that is the .NET convention used and advocated by Microsoft. And when I'm explaining coding conventions to a new developer, it's far less hassle to just use Microsoft's rules than to explain why we have our own "special" rules.
Interestingly enough, Microsoft first called it IXMLHTTPRequest when it was first added to the MSXML library.
It was Mozilla that used the name XMLHttpRequest when it added the concept into Gecko, implementing the idea to mimic the MS interface. It has since become the defacto standard, tying all other implementations to Mozilla's decision.
You'd have to go spelunking in the Mozilla Bugzilla to see if you can find any reasoning for the caps change there, but I suspect that not much thought went into it and the lowercasing of the ttp part is accidental.
This is corroborated by the misspelling of the Microsoft interface in the nsIXMLHttpRequest interface definition (earliest revision in the Mozilla Mercurial repository):
Mozilla's XMLHttpRequest is modelled after Microsoft's IXMLHttpRequest
object. The goal has been to make Mozilla's version match Microsoft's
version as closely as possible, but there are bound to be some differences.
Best Answer
In C/C++, a number followed by a letter is considered to be a numeric constant and the string that follows, qualifies the type of the constant. So for example (these are VC++, not sure how standard they are):
So a) it is easier for the lexer as Daniel said but also b) it makes an explicit distinction since 0y might be a variable but 0u would never be. Plus other qualifiers, like "i64" were added way later than "l" or "u" and they want to keep the option open of adding more if needed.