and I personally can connect to it, especially the Interface and Exception suffix thing. But also the grouping by cohesion makes sense.
So I would like to discuss and possibly vote about two separate things here:
Change of CGL and naming conventions to ban the Interface and Exception suffix.
Discuss if grouping stuff by cohesion is a thing (subpackage would be a way to do it now) and if we want to think in that direction. I guess because we use so much convention over configuration it will be hard to change that, but why not think about it.
My personal point of view:
Sometimes it’s really nice to quickly see if I have an interface somewhere, but that is IMHO rather the result of the fact that we sometimes use methods of specific implementations that the interface not have, so getting stricter with the interface usage would make it rather unecessary to see if $something is an interface or not, up to the point where we could say that type hints against implementations are to be avoided (there will be quite some cases where that is not desireable or possible).
I never thought about the exceptions but IMHO it makes a lot of sense that it’s very clear when something is an exception and so it’s not really needed to suffix it.
I don’t see a reason to change that (always hate having to wonder about stuff in Doctrine being an interface or not, for example).
On the exception side, I like that you can read it naturally: throw new InvalidArgumentException() as opposed to throw new InvalidArgument() - you throw an exception not an invalid argument. Comparable to $email vs. $emailAddress.
And, if we change the CGL, we either have to adjust all code or accept the inconsistency that will be the result of not doing that. Either are an investment I’d rather not do.
I see.
Natural language is always a bit interpretation: throw new InvalidArgument()can be read as “throw (exception) because there was an InvalidArgument”.
I have been thinking a lot about this personally as well; and I’m kinda undecided on that.
For exceptions, I think the Exception suffix is pretty common (in PHP, in Java, in .Net). For interfaces, it is a little more difficult for me personally; as I personally like to follow the rule “short names are more important/central than long names”. Something like PersistenceManagerInterface is longer than PersistenceManager; although the former is way more important than the concrete implementation.
Now that I think of it, we could solve this dilemma in another direction as well: By renaming Doctrine\PersistenceManager to Doctrine\DoctrinePersistenceManager (same goes for Context classes). That’s one thing I’d like to add to the discussions: I personally think it is very helpful that “important” framework classes are distinguishable just by its name, i.e. we should name a class SecurityContext instead of just Context.
Interesting talk indeed. He almost convinced me even though I frankly didn’t expect that beforehand
I do agree to Karstens objection though
throw new Runtime()
doesn’t make sense, and all the base (and SPL) exceptions end on *Exception, too.
Regarding interfaces I agree that some issues could be solved if the IDE would mark it as such everywhere… But then again, the IDE could also strip off the “Interface” suffix and replace it by a neat little icon…
Apart from that we’d run into naming clashes if we’d remove those suffixes (and the Abstract prefix to be consistent).
Right… That’s an itch for so long already. I’m about to fix that for 3.0 now (we have many of those inconsistencies, but I start with the SecurityContext for now as it’s the most prominent one).
