Re: [PEPr] Call for votes on Web Services::Services_GeoNames

From: Date: Wed, 10 Dec 2008 13:59:01 +0000
Subject: Re: [PEPr] Call for votes on Web Services::Services_GeoNames
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-51263@lists.php.net to get a copy of this message
Laurent Laville a écrit :
David Jean Louis a écrit :
Laurent Laville a écrit :
David Jean Louis a écrit :
David Jean Louis (http://pear.php.net/user/izi) has initiated the call for votes on Web Services::Services_GeoNames. Please review the proposal and give your vote here: http://pear.php.net/pepr/pepr-proposal-show.php?id=550
Before to give my vote, I have one question : Sorry If I went out of "proposal exploration time boxe", but I was very busy these last days. I go through the Services_GeoNames source code, and I was surprised only by one detail: Usage of constant prefixed only by E_ for Exceptions. Don't found purpose about it in any PEAR2 Coding Standard notes (but perharps I don't search at the right place). Personally I think we could have collision/confusion with error_reporting constants [1] [1] http://www.php.net/manual/en/errorfunc.constants.php
Hi Laurent, I'm not sure this is a big issue since theses constants are *class constants* and thus in the class namespace.
Totally agree with you. Just disturbing me a moment
That's said if there's some conscensus about exceptions codes constants naming, I'll be ok to change their names, the package being beta there will be bo BC worries.
I'd like to have status of PEAR QA about this *class constants* usage but consider already that you've my vote +1
Chuck pointed me to the actual specs for constants that recommends prefixing them with the name of the package to uppercase: http://pear.php.net/manual/en/standards.naming.php I think this does not make sense for class constants (it's quite redundant to type Services_GeoNames::SERVICES_GEONAMES_SOME_CONSTANT). I'd just remove the "E_" prefix. -- David

« previous php.pear.dev (#51263) next »