Re: [PEPr] Comment on Util::Util_Observable

Alan Knowles wrote: > > Heino H. Gehlsen wrote: > > > >Alan, although it’s correct that the double underscores are not common > > use in PEAR, they serve a distinct purpose, since they are used to > > differentiate between primary and secondary classes in the same file. > > Not in pear, and have never done so, they primarily indicate a heirachy > which has a distict and strong relationship to file location - this for > me is one of the most important features of PEAR, I'm never left in the > situation, that I have to go hunting around to find the source to any > Class. It's nice to see that see people are so convinced with PEAR, but how about a little class hunting? For starters there classes are not located according to the convention: SOAP_Attachment (located in SOAP/Value.php !), MDB2_Driver_Common and MDB2_Result_Common (both actually located in MDB2.php !), PEAR_Error, DB_Error, DB_Result, DB_Row, a lot of Net_SmartIRC_* and HTML_TreeMenu_*, XML_RPC_Base, XML_RPC_Client, XML_RPC_Response, SOAP_WSDL_Parser. Wow, I just had a WTF is the source code... > As apposed to C, Java and C# where I either have to grep entire > source trees or google for the definition (this wastes alot of my time, > and is something that infuriates me no end..). It now appears that PEAR has such a problem too. My code however doesn't due the extra underscore! > > This prevents future conflicts since such secondary classes don’t > > break the classic naming. Take the DB.php file in PEAR for instance; > > it includes multiple classes too: DB, DB_Error, DB_result etc. Such > > class names would conflict with a possible future file named > > DB/Error.php, which would have precedence according to the > > naming convention. Like it or not, but that’s my reasoning for using > > double underscores.. > > > Just because you "can" add a rocket to a car doesnt mean that everybody > is going to blow them selves up.. - this is a very loose argument. 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... > > As for you complaint about the WTF is the source, I believe the above > > explanation should be enough to prove that the "WTF is the source for > > this" syndrome has been taken care of. > > No it doesnt help at all - you are still left with the situation, I'm reading Mail/smtp.php, and it has a method > function observer(Util__iObservable $xxxx) { > ..... > > Where am I supposed to find that interface - to check it matches what I want to send it? I've already explained how to interpret the double underscores (but I guess it's hart to learn an old dog new tricks); Util__iObservable would of cause be located in Util.php, since the double underscores tells you (or at least those who accept the addition to the convention) that it's a secondary class. Please note that only one extra underscore would be allowed per class name, since it wouldn't make sense adding multiple levels of secondary classes in the same file! > - I'm going fishing again: > Whereas : > > function observer(Util_Observable_Interface $xxxx) { > ..... > > I know exactly where I will find it: > > >Also the above explanation should explain why I personally don’t like your “Util_Observer_Interface_* all stored in Util/Observer/Interface.php” suggestion. With the current class mess in PEAR in mind, you might as well propose that every "Util_Observer_Interface_*" should be stored in Util/Observer.php. It really doesn't matter that does it? Well I for one don't like it, and as for having WTF is the source code, I think your proposed location of Util_Observer_Interface_* classes in Util/Observer/Interface.php is much worse than my extra one underscore. > Why? - the "because it involves typing too much" seems the only viable > justification for your logic, and that doesnt hold much water when you > are delivering code that has to be re-used by others. Isn't it amazing that people tend to forget other peoples explanations so damn quickly, or simply wont take them as a difference in opinions. The "because it involves typing too much" is your choice of words, and I most certainly don't believe in them personally, since I would prefer prepending 'PEAR_' on every class or file etc. in PEAR to prevent conflicts with other repositories from happening. 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. Regards, Heino