In the recent RFC: New Validation Component topic emerged an argument that I think deserves one of its own.
The article points out good questions about the conventionts used today in PHP world, and I agree with most of them, somewhere fully, somewhere only in the idea of questioning habits.
However I fully disagree on the first point, and in a big project like ZF I think it deserves at least public discussion.
Talking about habits, we need to split the topic in two part:
- whether or not a convention is good
- impacts of a convention change
The misunderstanding and misusing of interfaces and implementations cited in
Naming chapter are real, but they are only an evidence of the bad habits cited in the paragraphs that follow.
Of course having a
TranslatorInterface and a
Translator confuses people on what should be typehinted, but that’s not an issue with naming, it’s an issue of a
Default implementation and having no reason to create an interface.
zend-cache\Storage is a good example: there is no default cache storage, so there is no
Storage class, but it makes sense to have an interface with the abstract concept of storage named
The article also say that typehinting against something with
Interface suffix is superfluous:
The interface […] is the essential concept, the thing that clients use. They don’t care whether [the typehint] is a concrete class or an interface, and they don’t care how it’s implemented. The client wants to be decoupled from all those details.
Well, I think that isn’t always true, sometimes there is a need for a strict coupling with a specific implementation.
When I read the
Interface part on a typehint I think “Ok this object uses an external API, but it isn’t coupled to a specific implementation, I can understand this object alone”.
When I don’t see it I think “If I need to know what this object is doing, I have to read the dependency behaviour first”.
These thoughts have huge impacts on the easiness of comprehension of external libraries.
For example Doctrine (used to) use only
EntityManager class typehints because complex database behaviours are coupled strictly coupled with results, and the implementation can be only one; for an advance usage of Doctrine, a developer must read some of its code.
In the other part different zend-cache\Storages can be switched without caring much the code because the expected behaviours are the same across storages.
And all this can be immediately known by just a single suffix.
If there would be no
Interface suffix, I will have to open the typehint to know what to expect in term of coupling.
Regarding the suffix making interfaces first-class citizen, I disagree: classes don’t have
Class suffix not because they are or aren’t special, but just to be less verbose.
I would find it right to use
Class suffix, we don’t do it because implying it saves us a lot of words to write and read.
Zend Framework Naming Conventions speed up a lot the comprehension of the library.
Consistency across the whole project is a mandatory requirement for a developer in order to trust the framework, otherwise the learning curve would be infinite.
If the maintainers or the community agree to change a convention, I expect it to be a breaking change, and so bumping a major version.
As said the suffix change was seen in the RFC: New Validation Component topic. The current zend-validator version is 2, and I suppose the RFC proposal is for v3.
There already are some components of Zend Framework bumped to v3. Even if now the components are splitted, If I’m using only v3 components I would be very, very, very confused to see the Interface suffix somewhere, and not seeing it somewhere else.
If new conventions are going to be adopted, I would expect, or at least hope, to see them only in v4.
Comments to the original article worth the reading.
What are your thoughts?