Re: [PEPr] Comment on Util::Util_Observable

Heino H. Gehlsen wrote:

Why leave a rocket in the car when you don't have to? Why is it such a bad thing to prevent future conflicts by simply adding an extra underscore between the primary class (which is located correctly according to the current coding standard) and the secondary classes (which wouldn't be allowed to exist there according to the current coding standard) ? Currently the correct way would of cause be to waste flops by having the OS and the engine finding and parsing multiple very small files...

First, thanks for having posted the proposal in the first place. Interfaces are a new feature of PHP5, and a "example" package is always good to see how things can be implemented... While the PEAR naming convention may not be perfect due to possible conflicts, I suppose this fact was considered, pondered, acknowledged and then accepted as a minor inconvenience compare to the advantage of simple source file organization. We can live with the fact of not being able to create packages named "Interface"... If anything, the name API could be used instead of "Interface" in the name... I think the double underscore is introducing a second naming convention, which for something as simple as naming is a bit overkill. As far as where to put the interface declarations, in the case of observer/observable, one file could be tolerated since I hardly see why one interface would be used and not the pending one. (This for performance reasons.)

The example with the location of DB_Result should in my honest opinion be more then enough to justify my private addition to the naming convention (speaking of which I have for the record not even said anything about adding this concept to the official coding standard. I have even from the start made it clear that the proposed code was only loosely rewritten to fit into the proposal, and I asked people to spare me for silly comments about the coding standard.

Right, that's why I think it would be best to separate things into topics: - Naming convention for interfaces: Append "Interface", "API" (with or without leading underscore)... or prepend? or insert __i... whatever * Personally, I like appending _Interface... It doesn't leave room for much guessing... - For observer pattern itself: what method names to use? and how many interfaces need to be declared? - Where to place interface in the PEAR "directory". Under a new "Interface" category? The closest category to the actual implementation, for instance: "Utils", "Pattern"... whatever * IMHO "Utils" are for standalone applications or alike: PHPDoc... Not tools for programming per se... * Observer is a programming pattern that help assing notifications around, so appropriate categories would be (in order of my preference) 1. Programming 2. Pattern 3. Processing Hey what the heck, it could even go under: 4. PHP 5. Logging Now it would be nice if everyone could agree on something without insulting each other... -Philippe