Re: Re: Function naming in the procedural world
| From: | Greg Beaver | 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