Posted: Fri Sep 29, 2006 9:12 pm
Though much of the post was OT here are some thoughts:
- I don't see how PEAR having a library feel, redundant classes, Zend's peer review, you not needing MVC (ZF does not require it), or when MVC makes sense have anything to do with class/file naming.
- I think you mean "low coupling" not "loose coupling" which is a data interchange term.
- I don't think exposing directory structure to the "client" (whatever that means) is more or less useful to any developer.
- The number one rule of OOD is not Open/Close. It is a good guideline, but composition is favored over extension these days. The idea that "you should never need to modify your class API *ever*" is completely unrealistic in my view.
- I don't think that changing interfaces is related necessarily means fragility, and by you definition it is only actual side effects that are a "problem."
- While class name are part of that interface contract, they are a trivially changable part -- as opposed to parameters and methods for example. Though I agree with your reason to avoid statics.
- Class name changes will not "reverberate throughout your source tree" because name changing is easy. And if you move a file and rename it in other systems you will have the same amount of work.
- You example of "Zend_Security_Libs_Crypt_Md5" is just opinion as to whether the information in the name is useful or useless -- it does convey meaning and I don't see how the same organizational information in not useful both places.
- It is easy to throw out a list like Fragility, Rigidity, Immobility, and Viscosity. I do not believe that naming/renaming is anywhere near a key cause of Fragility and Rigidity (again like methods/parameters). Regarding Immobility, it seems that the uniqueness of PEAR style names would improve reuse. Regarding Viscosity, PEAR naming would probably support keeping additions within the design better than other schemes. Nor do I see how any of those concepts has to do with "rot".
- Not sure how "include path's are not part of the component contract" makes sense here, especially because you are comparing compiled and linked languages to PHP which uses the run-time include() concept, which is different than even packages. PEAR naming is a solution to a problem that does not exist in the example languages you mention.
- Repeating "There should be no hardened relationship between source code and source tree does not make is so. The naming is part of the interface, but again is not anywhere near like changing parameters or methods when it comes to low coupling. Changing names requires search/replace; changing methods or parameters requires recoding.
- You say "but not everyone has a IDE that powerful." while saying that this is really an issue of large projects that would certainly use a powerful IDE.
- PEAR naming was designed to make "class names constructed on the fly" easier in PHP -- a class cannot be instantiated until included -- that's the point of the connection between the class and the file path.
- One of the reasons that Zend used PEAR naming is that it has proved to "to appeal to the widest audience possible."
- include() is not most typically hardcoded in PHP frameworks and class loading is an integral part of them. Comparisons to compiled langauges is not really pertinent.
- In my experience source trees are not that volatile and public interfaces do sometimes change.
- PEAR naming, because if it uniqueness supports "having a component which "drops" right into your application and you never have to worry about it again." That is another reason why Zend chose that style naming. You only need to look at their growing component library to see this.
- I don't see how PEAR having a library feel, redundant classes, Zend's peer review, you not needing MVC (ZF does not require it), or when MVC makes sense have anything to do with class/file naming.
- I think you mean "low coupling" not "loose coupling" which is a data interchange term.
- I don't think exposing directory structure to the "client" (whatever that means) is more or less useful to any developer.
- The number one rule of OOD is not Open/Close. It is a good guideline, but composition is favored over extension these days. The idea that "you should never need to modify your class API *ever*" is completely unrealistic in my view.
- I don't think that changing interfaces is related necessarily means fragility, and by you definition it is only actual side effects that are a "problem."
- While class name are part of that interface contract, they are a trivially changable part -- as opposed to parameters and methods for example. Though I agree with your reason to avoid statics.
- Class name changes will not "reverberate throughout your source tree" because name changing is easy. And if you move a file and rename it in other systems you will have the same amount of work.
- You example of "Zend_Security_Libs_Crypt_Md5" is just opinion as to whether the information in the name is useful or useless -- it does convey meaning and I don't see how the same organizational information in not useful both places.
- It is easy to throw out a list like Fragility, Rigidity, Immobility, and Viscosity. I do not believe that naming/renaming is anywhere near a key cause of Fragility and Rigidity (again like methods/parameters). Regarding Immobility, it seems that the uniqueness of PEAR style names would improve reuse. Regarding Viscosity, PEAR naming would probably support keeping additions within the design better than other schemes. Nor do I see how any of those concepts has to do with "rot".
- Not sure how "include path's are not part of the component contract" makes sense here, especially because you are comparing compiled and linked languages to PHP which uses the run-time include() concept, which is different than even packages. PEAR naming is a solution to a problem that does not exist in the example languages you mention.
- Repeating "There should be no hardened relationship between source code and source tree does not make is so. The naming is part of the interface, but again is not anywhere near like changing parameters or methods when it comes to low coupling. Changing names requires search/replace; changing methods or parameters requires recoding.
- You say "but not everyone has a IDE that powerful." while saying that this is really an issue of large projects that would certainly use a powerful IDE.
- PEAR naming was designed to make "class names constructed on the fly" easier in PHP -- a class cannot be instantiated until included -- that's the point of the connection between the class and the file path.
- One of the reasons that Zend used PEAR naming is that it has proved to "to appeal to the widest audience possible."
- include() is not most typically hardcoded in PHP frameworks and class loading is an integral part of them. Comparisons to compiled langauges is not really pertinent.
- In my experience source trees are not that volatile and public interfaces do sometimes change.
- PEAR naming, because if it uniqueness supports "having a component which "drops" right into your application and you never have to worry about it again." That is another reason why Zend chose that style naming. You only need to look at their growing component library to see this.