Re: Re: Function naming in the procedural world

From: Date: Thu, 11 Jun 2009 16:24:45 +0000
Subject: Re: Re: Function naming in the procedural world
References: 1 2 3  Groups: php.standards 
Request: Send a blank email to standards-+get-62@lists.php.net to get a copy of this message
Brian Moon wrote: >> This would translate well into >> >> <?php >> namespace vendor\file; >> function functionname(){} >> ?> >> >> However, I wonder if you are in essence doing the exact same thing as >> the proposed namespace naming for OOP? i.e. >> >> {vendor}_{package}_function >> >> You just define package as the file containing the function. > > Hmm, perhaps. Perhaps vendor is not the right name for our top level > though. Most OSS projects only have one offering. We have Phorum. > Its the project, the group, the app. All one name for all levels. > Now, something like Horde could have a true vendor and package > separation. Hi, Yes, but phorum is the "vendor" for phorum, and thus the standard still works. I believe part of the point of the standard should be the flexibility to define exactly what "vendor" and "package" means in the context of the application created by the folks doing the naming. Thus, in Phorum's case, clearly the vendor is putting out a single application with multiple components. The components are still part of the larger application, but that doesn't mean they aren't packages. For instance, if PEAR only provided the PEAR_PackageFileManager package, one could say the PEAR_PackageFileManager_Plugins package was just a component of the larger application and not a separate package because it can't function on its own, but it is still a package as we choose to define it for our purposes (technically it is a sub-package, but the point is about naming standard, not about how we choose to split things up). Greg

« previous php.standards (#62) next »