Re: Re: [PEPr] Comment on RFC::ProtectedMembers
| From: | Markus Wolff | Date: | Mon, 28 Jun 2004 12:04:52 +0000 |
| Subject: | Re: Re: [PEPr] Comment on RFC::ProtectedMembers | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31274@lists.php.net to get a copy of this message | ||
Bertrand Mansion wrote:
Justin Patrin wrote:Of course, it's not just the underscore which is the reason for a (very easy to adjust to) API break - the main reason is inconsistency in the naming of the properties: Some of them are in we_divide_words_with_underscores style and some of them use studlyCapsStyle, which is because originally I followed the style DB_DataObject had in its .ini file and when the package got accepted into PEAR, I started using studlyCaps to follow CS... now, before 1.0 comes out, it's time to clean up this mess before it's too late. And actually, these properties were never prefixed with an underscore, as they are always public and must always remain that way. We will introduce the fb_ prefix so noone will confuse FormBuilder settings with database field names in the DataObject classes. CU MarkusActually, I said that and it was for DB_DataObject_FormBuilder, not DB_DataObject. The variables are members of DataObjects, but they're used by FormBuilder. This is a non-issue anyway as we're planning on changing it to fb_ before 1.0 to make it obvious and not confuse them with private vars.Because of an underscore, you break your API... So, will you fb_ prefixed variables be private, protected or public ?