Re: [CFV] how to mark protected items?

From: Date: Tue, 22 Jun 2004 20:52:52 +0000
Subject: Re: [CFV] how to mark protected items?
References: 1 2 3 4 5 6 7 8 9  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-31124@lists.php.net to get a copy of this message
Daniel Convissor wrote:
On Tue, Jun 22, 2004 at 04:08:44PM -0400, Hans Lellelid wrote:
They're screwed anwyay, Dan. Any PEAR package that is gonna upgrade to PHP5 is going to do so to take advantage of new language features.
In the long term, that's not necessarily the case.
Yeah ... that makes no sense to me. Perhaps nostalgia for the lost limitations of PHP4 will kick in at some point?
There is no easy migration path for user schmoe when all of a sudden the underlying package starts throwing PEAR_Exception instead of returning PEAR_Error.
Okay. But why add yet another bump in the road?
Because classes are probably going to be drastically re-designed for PHP5 -- and they will definitely be a new major revision & by definition not backwards compatible. Those properties may not even be part of the PHP5 version of the class -- protected or not. PLUS what you're suggesting will only help those who didn't bother reading the PHP4 API docs and were using the class wrong the entire time!
IMHO upgradeablity should not be a consideration when designing coding standards
I disagree.
Certainly you're free to ;) but you should quote the entire statement at least: "...coding standards that will apply to PHP5". Because PHP5 is not backwards compatible; there's no mitigation in var naming conventions when apps have to be redesigned from the ground up.
The underscores are helpful cues even when using PHP 5.
That's only true if your default design strategy is to expose your class properties as public. I think, in closing, that we clearly just disagree on this. That's ok. Two last points: - I wouldn't care about this discussion, except that you are proposing a rule (not a recommendation) that will apply to PHP5 code. Furthermore, you are proposing & arguing this without, apparently, ever having built tools using the new PHP5 object model. PHP5 OO is not the same, quite simply. - Secondly, PEAR coding standards are a big deal because they tend to serve as a guideline for many other PHP projects. PEAR packages tend to be fairly simple as compared to the many frameworks out there that implement PEAR coding standards. Regardless of your own feelings about the merits of data encapsulation and other OO best practices, the PEAR coding standards should be guidelines for the PHP community on the whole. Hans

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