[PHP-DEV] studlyCaps
Hi, I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite for a while ago. But I missed the important posts concerning the conclusion about this topic. are studlyCaps will be implemented consequently in mysqli and sqlite extensions? thanks in advance! Sabine Seipel -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] studlyCaps
Yes they will be implemented. The only extension which might not follow it is MySQLi because the author refuses to change it :'( Andi At 02:51 AM 4/4/2004 +0200, Sabine Seipel wrote: Hi, I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite for a while ago. But I missed the important posts concerning the conclusion about this topic. are studlyCaps will be implemented consequently in mysqli and sqlite extensions? thanks in advance! Sabine Seipel -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Sun, 2004-03-28 at 04:35, Zeev Suraski wrote: Very well put. +1 for consistency and going all the way with StudlyCaps from me. +1 for consistency, but unless someone is willing to change Georg's extension for him I don't see this happening. John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hello Derick, Friday, March 26, 2004, 2:43:59 PM, you wrote: On Thu, 25 Mar 2004, Andi Gutmans wrote: OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Isn't the largest concern consistency here? We now have the oppurtunity to make our OO stuff consistent with the 3500 other functions; even the OCI ext made the move. There is no reason to have the Dom ext use studlyCaps; one of the guys on the Dom XML specs board is here at the conf and said there is no reason why it should use studlyCaps. So, that actually destroys the reason to use studlyCaps at all, so why not do the right thing and make PHP consistent with itself, ie. use under_scores for ALL functions and methods? I'm willing to prepare a patch to the source AND documentation to make that happen. And because I'm sure that because most people WANT consistency, I see very little against doing this. How do you change all PEAR classes (what was the original reason)? marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Sat, Mar 27, 2004 at 12:11:27PM +0100, Marcus Boerger wrote: How do you change all PEAR classes (what was the original reason)? marcus As far as i can see, that is not neccessary. PEAR naming and PHP naming would only conflict if a PEAR class extends a PHP class. And i fail to see cases where that would happen... For example, if a DB Abstraction package is used to wrap an OO API, it would proxy method calls and translate them instead of extending the db-connection class (because that would mean any db that the abstraction package handles has to have the same API, and if that was the case, an abstraction layer is useless.) -- Regards, Stefan Walk [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Quoting Stefan Walk [EMAIL PROTECTED]: As far as i can see, that is not neccessary. PEAR naming and PHP naming would only conflict if a PEAR class extends a PHP class. And i fail to see cases where that would happen. That doesn't mean it's not going to happen. Try to be a little forward-thinking. -chuck -- Regard my poor demoralized mule! - Juan Valdez -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On 27 Mar 2004 at 10:10, Chuck Hagenbuch wrote: Quoting Stefan Walk [EMAIL PROTECTED]: As far as i can see, that is not neccessary. PEAR naming and PHP naming would only conflict if a PEAR class extends a PHP class. And i fail to see cases where that would happen. That doesn't mean it's not going to happen. Try to be a little forward-thinking. Also think about interfaces like the new iterators and exceptions which will surely replace the current PEAR error handling once PHP5 is out... -- Ferdinand Beyer [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hi, ok since I have seen a few arguments reoccuring I have decided to make a list of all arguments brought forth. Its in no way a judgement on any argument listed, nor does it list the arguments in any particular order. Therefore, the first one to tell me to remove something because the argument is bogus will have to buy me a kiba (cherry-banana juice; fyi cherry means kirsche in german) next time we meet. This list is just to keep track of the arguments made, however stupid they may be in the hope that we dont have to hear it again. The list can be found here: http://www.backendmedia.com/PHP/toStudlyCapOrNotToStudlyCap.txt If you think the file name is stupid so be it :-) Anyways I have heard reports of people having issues to reach my host. I hope my sys admin will address this issue promptly in case it persists. I am sorry for any possible inconvinience. Maybe we also need to make a list of all votes, especially separating the internals developers from the rest as it seems there was also an argument what side really had the most votes? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Sat, 2004-03-27 at 19:20, Lukas Smith wrote: Hi, ok since I have seen a few arguments reoccuring I have decided to make a list of all arguments brought forth. Its in no way a judgement on any argument listed, nor does it list the arguments in any particular order. Therefore, the first one to tell me to remove something because the argument is bogus will have to buy me a kiba (cherry-banana juice; fyi cherry means kirsche in german) next time we meet. This list is just to keep track of the arguments made, however stupid they may be in the hope that we dont have to hear it again. The list can be found here: http://www.backendmedia.com/PHP/toStudlyCapOrNotToStudlyCap.txt If you think the file name is stupid so be it :-) Anyways I have heard reports of people having issues to reach my host. I hope my sys admin will address this issue promptly in case it persists. I am sorry for any possible inconvinience. Maybe we also need to make a list of all votes, especially separating the internals developers from the rest as it seems there was also an argument what side really had the most votes? Don't take this personally please. My voice doesn't count for much on this list but I do generally read most of the posts. I watched with interest last year when this thing first became an issue, and now I think the whole issue has become retarded. It's like watching a pathetic government debate unfold with for the second time after a consensus was already realized. I think the couple of rogue developers who are against StudlyCaps should suck it in, get with the program, and next time read the mailing lists when they get back from supposed holiday. I mean really, how could the previous StudlyCaps debate have been missed? Were they on holiday for a month? Personally I have a gut feeling some people just chose not to make the move to StudlyCaps with the hope that if they waited long enough (something like after RC1) then they could profess it's too damn late to make the change. Seriously, I think PHP could only benefit from the consistency now rather than later. With a major version release I think this is more true than at any other time. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
you have two (2) number four's (4) on your list. Hi, ok since I have seen a few arguments reoccuring I have decided to make a list of all arguments brought forth. Its in no way a judgement on any argument listed, nor does it list the arguments in any particular order. Therefore, the first one to tell me to remove something because the argument is bogus will have to buy me a kiba (cherry-banana juice; fyi cherry means kirsche in german) next time we meet. This list is just to keep track of the arguments made, however stupid they may be in the hope that we dont have to hear it again. The list can be found here: http://www.backendmedia.com/PHP/toStudlyCapOrNotToStudlyCap.txt If you think the file name is stupid so be it :-) Anyways I have heard reports of people having issues to reach my host. I hope my sys admin will address this issue promptly in case it persists. I am sorry for any possible inconvinience. Maybe we also need to make a list of all votes, especially separating the internals developers from the rest as it seems there was also an argument what side really had the most votes? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Thu, 25 Mar 2004, Andi Gutmans wrote: OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Isn't the largest concern consistency here? We now have the oppurtunity to make our OO stuff consistent with the 3500 other functions; even the OCI ext made the move. There is no reason to have the Dom ext use studlyCaps; one of the guys on the Dom XML specs board is here at the conf and said there is no reason why it should use studlyCaps. So, that actually destroys the reason to use studlyCaps at all, so why not do the right thing and make PHP consistent with itself, ie. use under_scores for ALL functions and methods? I'm willing to prepare a patch to the source AND documentation to make that happen. And because I'm sure that because most people WANT consistency, I see very little against doing this. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Quoting Derick Rethans [EMAIL PROTECTED]: On Thu, 25 Mar 2004, Andi Gutmans wrote: OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Isn't the largest concern consistency here? We now have the oppurtunity to make our OO stuff consistent with the 3500 other functions; even the OCI ext made the move. There is no reason to have the Dom ext use studlyCaps; one of the guys on the Dom XML specs board is here at the conf and said there is no reason why it should use studlyCaps. So, that actually destroys the reason to use studlyCaps at all, so why not do the right thing and make PHP consistent with itself, ie. use under_scores for ALL functions and methods? I'm willing to prepare a patch to the source AND documentation to make that happen. And because I'm sure that because most people WANT consistency, I see very little against doing this. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I support Derick 100% . Maybe my opinion does not count but better say it than being silent. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
I should also mention that majority, if not all of the users whom I spoke to at the Montreal conference seem to prefer to have PHP stick to a single naming convention that they are familiar with rather then use 2 distinct naming conventions. They were even able to raise some valid points we had not previously considered. For example it appears that it is quite common for people to use studlyCaps syntax to naming their own functions/methods, which allows them to easily distinguish between native PHP functions methods and the ones they wrote themselves. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 9:16 AM, Ilia Alshanetsky wrote: I should also mention that majority, if not all of the users whom I spoke to at the Montreal conference seem to prefer to have PHP stick to a single naming convention that they are familiar with rather then use 2 distinct naming conventions. They were even able to raise some valid points we had not previously considered. For example it appears that it is quite common for people to use studlyCaps syntax to naming their own functions/methods, which allows them to easily distinguish between native PHP functions methods and the ones they wrote themselves. The StudlyCaps standard only applies inside OO code, so I see this as much less of an issue (certainly no worries of conflicts). In case it's not obvious, I'm +1 for StudlyCaps. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On March 26, 2004 09:23 am, George Schlossnagle wrote: The StudlyCaps standard only applies inside OO code, so I see this as much less of an issue (certainly no worries of conflicts). Not entirely true, since PHP5 has quite a bit of native OO code, it would prevent people from easily making a distinction between native and user created classes/interfaces. It is by no means a deciding problem, but yet another reason to avoid studlyCaps. In case it's not obvious, I'm +1 for StudlyCaps. Thanks for clarifying ;) Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Friday 26 March 2004 15:27, Ilia Alshanetsky wrote: Not entirely true, since PHP5 has quite a bit of native OO code, it would prevent people from easily making a distinction between native and user created classes/interfaces. It is by no means a deciding problem, but yet another reason to avoid studlyCaps. So one would inherit from/extend a native class and then use studlyCaps and call underscore style methods from parent class. Can you imagine how ugly would this look? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Edin Kadribasic wrote: On Friday 26 March 2004 15:27, Ilia Alshanetsky wrote: Not entirely true, since PHP5 has quite a bit of native OO code, it would prevent people from easily making a distinction between native and user created classes/interfaces. It is by no means a deciding problem, but yet another reason to avoid studlyCaps. So one would inherit from/extend a native class and then use studlyCaps and call underscore style methods from parent class. Can you imagine how ugly would this look? actually Ilia this argument was raised before, but as Edin points out its not at all useful in OO since you generally want to use OO to be able to extend the code. regards, Lukas Smith [EMAIL PROTECTED] ___ BackendMedia www.backendmedia.com [EMAIL PROTECTED] Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 9:38 AM, Ilia Alshanetsky wrote: On March 26, 2004 09:35 am, you wrote: So one would inherit from/extend a native class and then use studlyCaps and call underscore style methods from parent class. Can you imagine how ugly would this look? It may look ugly, but without a doubt it would be very clear which code is 'user' and which is 'PHP'. Ugliness in general makes code difficult to read, in this case (IMO) it actually makes the situation a little clearer. As Edin and Lukas have both pointed out, one of the major precepts of OO programming is that you can (and often do) overload methods in your parent. Adopting two different styles really doesn't work if you ever want to use any of the in-core classes, as it will force your own code to adopt both notions. In fact, the argument that people use StudlyCaps in their own code is precisely why it should be adopted in OO code, so that overloading won't result in a mishmash of styles. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Fri, Mar 26, 2004 at 09:53:28AM -0500, George Schlossnagle wrote: As Edin and Lukas have both pointed out, one of the major precepts of OO programming is that you can (and often do) overload methods in your parent. Adopting two different styles really doesn't work if you ever want to use any of the in-core classes, as it will force your own code to adopt both notions. In fact, the argument that people use StudlyCaps in their own code is precisely why it should be adopted in OO code, so that overloading won't result in a mishmash of styles. You'll have that mishmash of styles anyway if you use camel case naming, since the vast majority of existing functions doesn't use it. I don't see that 'being able to distinguish between built-in and user-defined' thing as valid either, but if you want real consistency you'd go and make everything conform to ONE naming standard. There's no reason that methods should be different from functions at all. In a way, functions are just methods with PHP as the implicit reciever... Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe make strpos an alias to str_pos or alike... -- Regards, Stefan Walk [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] studlyCaps conclusion
sarcasm
Lets create an engine level option, lets calls it coding_convention.
The default is studlyCaps.
Consider the following code:
$foo-fooBarBaz();
When coding_convention=studlyCaps, the engine will resolve the method
thus (psuedo code):
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_underscored_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
When coding_convention=underscores, the engine will resolve it thus:
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_studly_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
For the speed concious, there will be a configure option to either
remove the coding convention checks completely.
This approach will keep allow us to keep whichever coding style
we end up deciding on (although I suspect we won't reach a decision
until PHP 7), while meanwhile allowing the end user a transparent
choice of their preference for PHP methods.
/sarcasm
Let's stop arguing about this stuff--we all have MUCH more important
things to do with our time.
My point of view on this:
- The guideline is to stick with studlyCaps for OO extensions for
consistency with PEAR.
- New OO extensions SHOULD try to follow the guideline, but are not
required to (no need to create more work for our limited developer
resources).
Now, if the authors/maintainers of an OO extension want to change to
studlyCaps, let them do so (I have no objection to SQLite OO api being
changed), but lets not force people that otherwise have no time and
have spent a lot of effort over a long period of time (eg: Georg) to
rewrite their extensions. [keep in mind that one of the reasons that
mysqli was written the way it is to keep it closer to the native
library API; changing that is just re-introducing a nightmare for the
maintainer.]
I've said my piece; lets get over it and get on with it.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Fri, 26 Mar 2004, Stefan Walk wrote: Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe make strpos an alias to str_pos or alike... So you are saying strlen() should be str_len() as well? If I ever see a patch to change that I'll hunt the person down and make them swallow an entire KR C book. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Fri, Mar 26, 2004 at 07:05:15AM -0800, Rasmus Lerdorf wrote: On Fri, 26 Mar 2004, Stefan Walk wrote: Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe make strpos an alias to str_pos or alike... So you are saying strlen() should be str_len() as well? If I ever see a patch to change that I'll hunt the person down and make them swallow an entire KR C book. -Rasmus Well, C is consistent in that it doesn't use underscores there. If no underscores at all would be used, i wouldn't complain either. But the way it is now is inconsistent... and using a different naming convention for member functions a.k.a. methods introduces new inconsistency. I know that it's not possible to kill all existing inconsistencies, but why introduce new ones? -- Regards, Stefan Walk [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] studlyCaps conclusion
I pretty much agree with Wez. A bad decision is worse than no decision :)
The way I see it, studlyCaps has been in the CODING_STANDARDS *and*
precisely because people and PEAR use them for method names we should go
with studlyCaps. It would suck to have user-land and internal methods look
differently. Personally I think it makes sense to keep underscores for
functions and I see no problem with them differing from methods as I
usually use underscores for C code and studlyCaps for C++ code :)
We should go with studlyCaps according to CODING_STANDARDS for all
extensions. If some extension writer refuses (such as George) then so be it
and we leave it the way it is (although I would ask him to reconsider for
the long term good of PHP).
Andi
At 03:01 PM 3/26/2004 +, Wez Furlong wrote:
sarcasm
Lets create an engine level option, lets calls it coding_convention.
The default is studlyCaps.
Consider the following code:
$foo-fooBarBaz();
When coding_convention=studlyCaps, the engine will resolve the method
thus (psuedo code):
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_underscored_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
When coding_convention=underscores, the engine will resolve it thus:
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_studly_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
For the speed concious, there will be a configure option to either
remove the coding convention checks completely.
This approach will keep allow us to keep whichever coding style
we end up deciding on (although I suspect we won't reach a decision
until PHP 7), while meanwhile allowing the end user a transparent
choice of their preference for PHP methods.
/sarcasm
Let's stop arguing about this stuff--we all have MUCH more important
things to do with our time.
My point of view on this:
- The guideline is to stick with studlyCaps for OO extensions for
consistency with PEAR.
- New OO extensions SHOULD try to follow the guideline, but are not
required to (no need to create more work for our limited developer
resources).
Now, if the authors/maintainers of an OO extension want to change to
studlyCaps, let them do so (I have no objection to SQLite OO api being
changed), but lets not force people that otherwise have no time and
have spent a lot of effort over a long period of time (eg: Georg) to
rewrite their extensions. [keep in mind that one of the reasons that
mysqli was written the way it is to keep it closer to the native
library API; changing that is just re-introducing a nightmare for the
maintainer.]
I've said my piece; lets get over it and get on with it.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 26, 2004, at 10:30 AM, Stefan Walk wrote: On Fri, Mar 26, 2004 at 07:05:15AM -0800, Rasmus Lerdorf wrote: On Fri, 26 Mar 2004, Stefan Walk wrote: Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe make strpos an alias to str_pos or alike... So you are saying strlen() should be str_len() as well? If I ever see a patch to change that I'll hunt the person down and make them swallow an entire KR C book. -Rasmus Well, C is consistent in that it doesn't use underscores there. If no underscores at all would be used, i wouldn't complain either. But the way it is now is inconsistent... and using a different naming convention for member functions a.k.a. methods introduces new inconsistency. I know that it's not possible to kill all existing inconsistencies, but why introduce new ones? No one is discussing changing the names of these functions. The standard being discussed is specifically limited to OO code, so please stop trying to take this discussion astray with such strawman arguments. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: Re: [PHP-DEV] studlyCaps conclusion
I meant A bad decision is better than no decision.
Date: Fri, 26 Mar 2004 17:32:13 +0200
To: Wez Furlong [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Andi Gutmans [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] studlyCaps conclusion
I pretty much agree with Wez. A bad decision is worse than no decision :)
The way I see it, studlyCaps has been in the CODING_STANDARDS *and*
precisely because people and PEAR use them for method names we should go
with studlyCaps. It would suck to have user-land and internal methods look
differently. Personally I think it makes sense to keep underscores for
functions and I see no problem with them differing from methods as I
usually use underscores for C code and studlyCaps for C++ code :)
We should go with studlyCaps according to CODING_STANDARDS for all
extensions. If some extension writer refuses (such as George) then so be
it and we leave it the way it is (although I would ask him to reconsider
for the long term good of PHP).
Andi
At 03:01 PM 3/26/2004 +, Wez Furlong wrote:
sarcasm
Lets create an engine level option, lets calls it coding_convention.
The default is studlyCaps.
Consider the following code:
$foo-fooBarBaz();
When coding_convention=studlyCaps, the engine will resolve the method
thus (psuedo code):
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_underscored_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
When coding_convention=underscores, the engine will resolve it thus:
if (!method_exists($obj, $methodname)) {
$tmp_method_name = convert_to_studly_name($methodname);
if (!method_exists($obj, $tmp_method_name)) {
error(undefined method $methodname);
}
$methodname = $tmp_method_name;
}
$obj-$methodname(...)
For the speed concious, there will be a configure option to either
remove the coding convention checks completely.
This approach will keep allow us to keep whichever coding style
we end up deciding on (although I suspect we won't reach a decision
until PHP 7), while meanwhile allowing the end user a transparent
choice of their preference for PHP methods.
/sarcasm
Let's stop arguing about this stuff--we all have MUCH more important
things to do with our time.
My point of view on this:
- The guideline is to stick with studlyCaps for OO extensions for
consistency with PEAR.
- New OO extensions SHOULD try to follow the guideline, but are not
required to (no need to create more work for our limited developer
resources).
Now, if the authors/maintainers of an OO extension want to change to
studlyCaps, let them do so (I have no objection to SQLite OO api being
changed), but lets not force people that otherwise have no time and
have spent a lot of effort over a long period of time (eg: Georg) to
rewrite their extensions. [keep in mind that one of the reasons that
mysqli was written the way it is to keep it closer to the native
library API; changing that is just re-introducing a nightmare for the
maintainer.]
I've said my piece; lets get over it and get on with it.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Re: [PHP-DEV] studlyCaps conclusion
On Friday 26 March 2004 16:43, Andi Gutmans wrote: I meant A bad decision is better than no decision. So this bad decision is to have a standard that everybody is free to ignore? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Re: [PHP-DEV] studlyCaps conclusion
At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote: On Friday 26 March 2004 16:43, Andi Gutmans wrote: I meant A bad decision is better than no decision. So this bad decision is to have a standard that everybody is free to ignore? It means that we change whatever extensions aren't studlyCaps to studlyCaps (except for MySQLi, i.e. this is why it's a bad decision) and make sure in future we stick to CODING_STANDARDS. I already said that personally I'd prefer for MySQLi to change too. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Re: [PHP-DEV] studlyCaps conclusion
On Friday 26 March 2004 16:54, Andi Gutmans wrote: At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote: On Friday 26 March 2004 16:43, Andi Gutmans wrote: I meant A bad decision is better than no decision. So this bad decision is to have a standard that everybody is free to ignore? It means that we change whatever extensions aren't studlyCaps to studlyCaps (except for MySQLi, i.e. this is why it's a bad decision) and make sure in future we stick to CODING_STANDARDS. I already said that personally I'd prefer for MySQLi to change too. Maybe the extensions that do not comply with the CODING_STANDARDS should find alternative ways of distribution. For example MySQL AB can distribute mysqli from mysql.com and then use any standard they please. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hello Ilia, Friday, March 26, 2004, 3:38:35 PM, you wrote: On March 26, 2004 09:35 am, you wrote: So one would inherit from/extend a native class and then use studlyCaps and call underscore style methods from parent class. Can you imagine how ugly would this look? It may look ugly, but without a doubt it would be very clear which code is 'user' and which is 'PHP'. Ugliness in general makes code difficult to read, in this case (IMO) it actually makes the situation a little clearer. Sorry, this pretty much sounds like lookinng for a straw... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
So, that actually destroys the reason to use studlyCaps at all, so why not do the right thing and make PHP consistent with itself, ie. use under_scores for ALL functions and methods? I'm willing to prepare a patch to the source AND documentation to make that happen. And because I'm sure that because most people WANT consistency, I see very little against doing this. +1 Fixing documentation is not a big deal, except mysqli (which is completly documented for procedural + oo-style, including working and tested samples for mostly every function/method/property) most of the extensions which supports procedural and oo-style don't have oo-documentation, so we only have to change aliases. Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Nuno Lopes wrote: I really hate the Studlycaps convention. I prefer the old dash. Decision was made. Why not use this only for new extensions? Do you know the pain to update all the docs??... mysqli, tidy and sqlite are _new_ extensions. At least from the perspective of PHP's user. You have changed Tidy and SQLite so far. Thats lots of work for me and for the documentation team. I would vote to use that convention just for new extensions. RC1 is out and the persons are already testing and trying out their scripts. Why make a script that worked in RC1 incopatible with RC2? IMHO RC1 was rushed. As some other releases before it. I would say PHP's developers should be alarmed by the global tone of comments that appeared on slashdot after RC1 was released. And I would vote even to revert the changed in Tidy and SQLite... Who prefers the Studly caps instead of the well used '_'? There was decision. Twice. Try to cope with it. Lenar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Now I understand it's kind of hard to force extension authors to change their own code but as I said in the past it's important to show some responsibility and follow the CODING_STANDARDS even if books/articles and stuff have been published with the old information (it's only function name changes). Marcus has already stepped up and showed his willingness to make many of the needed changes. Andi At 03:51 PM 3/24/2004 +0100, Sebastian Bergmann wrote: Marcus Boerger wrote: For me one thing counts consistency. Same here. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 25, 2004, at 9:29 AM, Andi Gutmans wrote: OK Guys. It's decision time. I suggested to move to studlyCaps and keep consistency with the new PHP 5 changes. If we go with this, I think we should make these changes ASAP and try and aim for RC2 within two weeks. Now I understand it's kind of hard to force extension authors to change their own code but as I said in the past it's important to show some responsibility and follow the CODING_STANDARDS even if books/articles and stuff have been published with the old information (it's only function name changes). Marcus has already stepped up and showed his willingness to make many of the needed changes. I didn't author any of the affected code, but I'm happy to help affect this change. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 09:14 AM 3/25/2004 -0600, John Coggeshall wrote: On Thu, 25 Mar 2004, Andi Gutmans wrote: Marcus has already stepped up and showed his willingness to make many of the needed changes. Actually, iirc Marcus reverted that change. yep because he wanted to wait until we reach a conclusion. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Marcus Boerger wrote: For me one thing counts consistency. Same here. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 12:55 AM 3/23/2004 +0100, Edin Kadribasic wrote: On Tuesday 23 March 2004 00:13, Marcus Boerger wrote: you may consider me responsible for this mess - i must admit i forgot about sqlite's oo api a long time ago since it is running...(i know lame excuse) Obviously if we're going for consistency (and I thing we should) sqlite oo iterface should be changed as well. Its now or never, and I think there is still time. That of course depends on php5 release master. So Andi your thoughts? I think that being consistent is important and we have almost missed the chance to be so. I am starting to see that people are already using PHP 5 to develop production applications (which are due later this year). In order to minimize the damage caused by changing to studlyCaps, I suggest we make the changes now and roll an RC2 within a week. At least this way, people who are starting to pick-up PHP 5 due to its RC status will not have to change their scripts. I saw the SQLite patch and I see that a couple of method names have been changed beyond studlyCaps (order was changed), e.g. unbuffered_query - queryUnbuffered(). The old MySQL extension uses the former so maybe we should stay consistent? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 2004-03-23 at 03:01, Andi Gutmans wrote: order to minimize the damage caused by changing to studlyCaps, I suggest we make the changes now and roll an RC2 within a week. At least this way, people who are starting to pick-up PHP 5 due to its RC status will not have to change their scripts. I'm hesitant that RC2 should just be rolled because of basically this one ultimately superficial change. John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 03:43 AM 3/23/2004 -0500, John Coggeshall wrote: On Tue, 2004-03-23 at 03:01, Andi Gutmans wrote: order to minimize the damage caused by changing to studlyCaps, I suggest we make the changes now and roll an RC2 within a week. At least this way, people who are starting to pick-up PHP 5 due to its RC status will not have to change their scripts. I'm hesitant that RC2 should just be rolled because of basically this one ultimately superficial change. Huh? Why would you want people who downloaded the RC1 to work with a deprecated API? And how does it matter if we release RC2 or not? We can release as many RCs as we want until we feel comfortable with the tree. In any case, there have been other fixes since RC1 and we're making a serious fix to ze1_compatibility_mode which didn't clone the objects correctly. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. you think it's not too much trouble? Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tuesday 23 March 2004 11:58, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. you think it's not too much trouble? Since we're at now-or-never point I guess the trouble would be worth it. I know its a lot of work but it should mostly be search replace type. The book authors are probably already aware of the risk of writing about pre-release version of opensource software. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 6:52 AM, Edin Kadribasic wrote: On Tuesday 23 March 2004 11:58, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. I've had stuff (not mysqli) change underneath me in my book. It's annoying, but it's a problem inherent to writing to a moving target. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
As one of the authors who is trying to hit this moving target, I don't think how an API change in PHP 5 is going to mess up something in my book should be a factor in deciding if it should be done. It is annoying as all hell, but last I checked PHP doesn't revolve around publishers and their authors... I'm +1 for the change, if that means anything :) John On Tue, 2004-03-23 at 09:00, George Schlossnagle wrote: On Mar 23, 2004, at 6:52 AM, Edin Kadribasic wrote: On Tuesday 23 March 2004 11:58, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. I've had stuff (not mysqli) change underneath me in my book. It's annoying, but it's a problem inherent to writing to a moving target. George -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
i'm with georg. then again, i never quite agreed with all your base is belonging to studlycaps, its a nice guideline for future code, but i don't see the the necessity of breaking old stuff, even if it hasn't been released yet, its been in the tree for well over a year. -sterling On Mar 23, 2004, at 2:58 AM, Georg Richter wrote: I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, beside changing c-code it's - changing documentation (english, german, spain and french) - changing all samples - changing testcases (incl. ~300 testscripts on my machine) - changing ~200 slides - changing 2 articles and 2 authors told me they don't have a chance to change it anymore in their books, they will be printed these days. you think it's not too much trouble? Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
What about using the old names as aliases for the new ones, triggering deprecation warnings when called? -- Ferdinand Beyer [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tuesday 23 March 2004 16:23, Ferdinand Beyer wrote: What about using the old names as aliases for the new ones, triggering deprecation warnings when called? Don't you think its a bit silly to keep BC with something that hasn't even been officially released yet? Depriciated things in the fist official release? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
First of I do not believe it is a good idea this late in the release cycle to change the API of the SQLite's OO interface, especially without a fallback mechanism. This change obsoletes all existing articles, tutorials, etc... and will definitely break scripts of early adopters, which would certainly not help further adoption of PHP and SQLite. I still maintain that studlyCaps is a poor choice for a naming convention, but that's another matter all together. If this change does stick, could we at least add aliases to SQLite that would allow the syntax (non-studlyCaps) to work. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Markus Fischer wrote: On Tue, Mar 23, 2004 at 04:23:12PM +0100, Ferdinand Beyer wrote : What about using the old names as aliases for the new ones, triggering deprecation warnings when called? +1 on this. This doesn't break those authors examples, at least not to the point that they won't work (it's a nice gesture) and also creates a transient time for the documentation team; and it's future proof; whatever that means ;) But it's a lame ass thing to do as those will be deprecated, and it makes larger hashtables - (a bit) slower. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Ferdinand Beyer wrote: What about using the old names as aliases for the new ones, triggering deprecation warnings when called? NO. - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
I'm +1 for the change, if that means anything :) Sure, your book isn't ready yet. Would be interesting to know your opinion if it would be printed already. And for closing the discussion: we had a) feature freeze and b) I removed EXPERIMENTAL and therefore I will not change it. Cheers! Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
--- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and why developers consider various APIs to be unintuitive. We should pick a standard, any standard, and stick to it. I dislike StudlyCaps as much as the next guy, but I think inconsistency is even worse. I thought this issue was decided a few months ago... Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote: --- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and attacking scripts is terrorism, thus georg's violation of a never agreed upon standard is in support of terrorism. thus php supports terrorism - i always thought that elephant was for smuggling nuclear material. wmd. all that because MySQLi's naming conventions violate the pleasure of some people on the list. Georg made his decision on this, and there are enough developers against it to backup his decision - can we please find another dead horse to beat? ;-) -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and why developers consider various APIs to be unintuitive. We should pick a standard, any standard, and stick to it. I dislike StudlyCaps as much as the next guy, but I think inconsistency is even worse. I thought this issue was decided a few months ago... Chris I really hate the Studlycaps convention. I prefer the old dash. Why not use this only for new extensions? Do you know the pain to update all the docs??... You have changed Tidy and SQLite so far. Thats lots of work for me and for the documentation team. I would vote to use that convention just for new extensions. RC1 is out and the persons are already testing and trying out their scripts. Why make a script that worked in RC1 incopatible with RC2? And I would vote even to revert the changed in Tidy and SQLite... Who prefers the Studly caps instead of the well used '_'? Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Tuesday, March 23, 2004, 8:32:51 PM, you wrote: Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and why developers consider various APIs to be unintuitive. We should pick a standard, any standard, and stick to it. I dislike StudlyCaps as much as the next guy, but I think inconsistency is even worse. I thought this issue was decided a few months ago... Chris I really hate the Studlycaps convention. I prefer the old dash. Why not use this only for new extensions? Do you know the pain to update all the docs??... You have changed Tidy and SQLite so far. Thats lots of work for me and for the documentation team. Nuno: I can believe and i am thankfull you did the work :-)) I would vote to use that convention just for new extensions. RC1 is out and the persons are already testing and trying out their scripts. Why make a script that worked in RC1 incopatible with RC2? And I would vote even to revert the changed in Tidy and SQLite... Who prefers the Studly caps instead of the well used '_'? To the list: From my perspective it seems we were to fast with RC1. I am still coding and fixing deep internal things and even in the middle of releasing RC1 we had to change features which affect much more ppl than mysqli's oo api which more or less noone uses so far (it was and is still a moving target). As a consequence i forgot to change SQLite's OO API earlier and to reming georg again of that issue - sorry for the inconvenience. For me one thing counts consistency. And don't tell me that it is problematic for our users to transliterate from dashed_names to studlyCaps. It is work for us (for example it took me like about two hours: coding, testing and discussing) but the result is bit ease of use for our users. best regards marcus
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 2004-03-23 at 12:58, Georg Richter wrote: Sure, your book isn't ready yet. Would be interesting to know your opinion if it would be printed already. Then I really wouldn't care. In either case, this entire thread is getting completely pointless. I don't care if studlyCaps or underscore_methods are used or not, I'd just like to see it be one or the other. Since everyone seems to have a major problem changing SQLite and MySQLi, perhaps for good reason -- what about just changing ext/tidy back to underscore_methods? At least then we'd be consistent, and probably wouldn't have as much of a negative impact as changing the database extensions would. John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hello John, Tuesday, March 23, 2004, 9:05:51 PM, you wrote: On Tue, 2004-03-23 at 12:58, Georg Richter wrote: Sure, your book isn't ready yet. Would be interesting to know your opinion if it would be printed already. Then I really wouldn't care. In either case, this entire thread is getting completely pointless. I don't care if studlyCaps or underscore_methods are used or not, I'd just like to see it be one or the other. Since everyone seems to have a major problem changing SQLite and MySQLi, perhaps for good reason -- what about just changing ext/tidy back to underscore_methods? At least then we'd be consistent, and probably wouldn't have as much of a negative impact as changing the database extensions would. I already changed SQLite because as far as i know there were only two extensions left which didn't follow studlyCaps convention which we agreed upon twice so far - even though ppl pretend we hadn't. The only other extension i spotted so far not following studlyCaps is ming - and that at least doesn't use dashes and is still experimental. And to say it again, i bet only a handful of ppl are using mysqli's oo api right now but many ppl use things like __toString() already. Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Marcus Boerger wrote: I already changed SQLite because as far as i know there were only two extensions left which didn't follow studlyCaps convention which we agreed upon twice so far - even though ppl pretend we hadn't. The only other extension i spotted so far not following studlyCaps is ming - and that at least doesn't use dashes and is still experimental. And to say it again, i bet only a handful of ppl are using mysqli's oo api right now but many ppl use things like __toString() already. Heh -- yes, I'd like to add that doing a find and replace on mysqli function names would be far, far easier than trying to track down all the places where I had used the implicit __toString() call through (string) casts and concatenation ... and echo/print ... (I'm sure I haven't found them all yet.) I also doubt that really anyone is using the mysqli OO API directly ... (I kinda would hope that people building PHP5 apps would be using some kind of db abstraction system, whether PDO or PHP-based.) just my [not-that-valuable] .02 Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 11:12 AM 3/23/2004 -0800, Sterling Hughes wrote: On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote: --- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and attacking scripts is terrorism, thus georg's violation of a never agreed upon standard is in support of terrorism. thus php supports terrorism - i always thought that elephant was for smuggling nuclear material. wmd. all that because MySQLi's naming conventions violate the pleasure of some people on the list. Georg made his decision on this, and there are enough developers against it to backup his decision - can we please find another dead horse to beat? ;-) Sterling. We did come to a decision on this mailing list. In case you were asleep, well read the archives. And no, I don't think we should make decisions about PHP based on books. Zeev's book with PHP 5 support came out a few months ago and we broke half the things which he wrote about it. He'll need to create a new edition and I don't remember him even once complaining about it, because he did what was best for PHP. The fact is that consistency is important for PHP, wether it is studlyCaps or underscores. We just happened to have decided on studlyCaps, if you don't like it then you had your chance to voice this when it was discuss on [EMAIL PROTECTED] We can't continue to open issues every month or two. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hi, what about just changing ext/tidy back to underscore_methods? Afaik I proposed that in a private mail to you months ago, cause you changed it after feature freeze when tidy was not in an experimental state. But you didn't reply :( Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! We are on the best way to become not reliable - or probably we are already! Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. Huh? Now you're really going to confuse people. You can always have RC2 and more. As it is there will be enough meat to have an RC2 after bug fixes (things which weren't discovered before more people started testing the RC). We decided on studlyCaps a while ago and I wasn't aware people here didn't apply this decision. Anyway, we are and where in a feature freeze but as I said, I didn't realize people didn't apply that decision. If there's a consensus we can stay with the way things are but I think it's dumb to do so just because an RC has been out for a few days. If we release an RC2 quickly it will be barely noticed. We will regret the inconsistency forever if we don't take care of it (which we already do with the functional part of PHP). If all of you prefer this inconsistency then so be it. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote: At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. Huh? Now you're really going to confuse people. You can always have RC2 and more. As it is there will be enough meat to have an RC2 after bug fixes (things which weren't discovered before more people started testing the RC). Two RC1s would be a clusterfuck. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, George Schlossnagle wrote: On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote: At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. Huh? Now you're really going to confuse people. You can always have RC2 and more. As it is there will be enough meat to have an RC2 after bug fixes (things which weren't discovered before more people started testing the RC). Two RC1s would be a clusterfuck. So call it RC2. The name is irrelevant. The important part is to let people know that there are some big code-breaking changes happening and that just because a freeze and an RC was announced nobody should count on features and functions being frozen yet. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 01:41 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, George Schlossnagle wrote: On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote: At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Georg Richter wrote: Changing everything after an announced feature freeze sucks. It's just ignoring others (users, authors and publishers) - a loss of face. Obviously some people like this kind of policy - me not! I do agree with this. There is no point in announcing a freeze if you turn around and change a bunch of fundamental things the next day. If we are really going to go back and change all these method names then I think the correct way to do it is to pull RC1 and let people know that we discovered some things that need to be cleaned up and we will attempt another freeze and RC1 at a later date. Huh? Now you're really going to confuse people. You can always have RC2 and more. As it is there will be enough meat to have an RC2 after bug fixes (things which weren't discovered before more people started testing the RC). Two RC1s would be a clusterfuck. So call it RC2. The name is irrelevant. The important part is to let people know that there are some big code-breaking changes happening and that just because a freeze and an RC was announced nobody should count on features and functions being frozen yet. I'm fine with an RC2 within a few days. I would do it latest on Monday. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Andi Gutmans wrote: So call it RC2. The name is irrelevant. The important part is to let people know that there are some big code-breaking changes happening and that just because a freeze and an RC was announced nobody should count on features and functions being frozen yet. I'm fine with an RC2 within a few days. I would do it latest on Monday. How about making sure there are no other basic issues like this outstanding first? If you are going to be the release master here it is actually your job to prod the right people and make sure they are ready as opposed to relying on folks to pipe up if they aren't ready. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
At 01:48 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Andi Gutmans wrote: So call it RC2. The name is irrelevant. The important part is to let people know that there are some big code-breaking changes happening and that just because a freeze and an RC was announced nobody should count on features and functions being frozen yet. I'm fine with an RC2 within a few days. I would do it latest on Monday. How about making sure there are no other basic issues like this outstanding first? If you are going to be the release master here it is actually your job to prod the right people and make sure they are ready as opposed to relying on folks to pipe up if they aren't ready. I don't think this kind of email is called for. I don't know what you call a basic issue but besides the studlyCaps issue there are no other basic issues. They are all bug fixes. I don't remember anyone else noticing this issue. Again, we can leave things the way they are but we are having a discussion now if we want to do so or not. Looking back at PHP's history I think the inconsistencies we have carried from the days of PHP/FI are something which shouldn't be repeated. Then again, I won't die if we leave things the way they are. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Andi Gutmans wrote: At 01:48 PM 3/23/2004 -0800, Rasmus Lerdorf wrote: On Tue, 23 Mar 2004, Andi Gutmans wrote: So call it RC2. The name is irrelevant. The important part is to let people know that there are some big code-breaking changes happening and that just because a freeze and an RC was announced nobody should count on features and functions being frozen yet. I'm fine with an RC2 within a few days. I would do it latest on Monday. How about making sure there are no other basic issues like this outstanding first? If you are going to be the release master here it is actually your job to prod the right people and make sure they are ready as opposed to relying on folks to pipe up if they aren't ready. I don't know what you call a basic issue but besides the studlyCaps issue there are no other basic issues. They are all bug fixes. Ok, if you are sure of that fine. But lets doublecheck with the authors of the main new components (sqlite, mysqli, simplexml) first and make sure they are all in sync. For example, Derek Ford's simplexml-related message to internals last week(*) worries me somewhat. He passed on what looks to be some basic brokeness in the extension which nobody has addressed so far. (*) http://news.php.net/article.php?group=php.internalsarticle=8660 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
We decided on studlyCaps a while ago and I wasn't aware people here didn't apply this decision. Hmm, looks like I was on vacation when decision was made. I only can remember that we agreed BEFORE feature freeze, to have studylCaps when the underlying api also supports it (like xml stuff). /Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 1:17 PM, Andi Gutmans wrote: At 11:12 AM 3/23/2004 -0800, Sterling Hughes wrote: On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote: --- Georg Richter [EMAIL PROTECTED] wrote: Sure, your book isn't ready yet. Is this really the criteria being used to support a lack of consistency? This sort of thing (inconsistency) is one reason why PHP is frequently attacked and attacking scripts is terrorism, thus georg's violation of a never agreed upon standard is in support of terrorism. thus php supports terrorism - i always thought that elephant was for smuggling nuclear material. wmd. all that because MySQLi's naming conventions violate the pleasure of some people on the list. Georg made his decision on this, and there are enough developers against it to backup his decision - can we please find another dead horse to beat? ;-) Sterling. We did come to a decision on this mailing list. In case you were asleep, well read the archives. I didn't say there was no decision - I said there was no agreement. And no, I don't think we should make decisions about PHP based on books. Zeev's book with PHP 5 support came out a few months ago and we broke half the things which he wrote about it. He'll need to create a new edition and I don't remember him even once complaining about it, because he did what was best for PHP. Well, if I honestly believed there were a practical advantage to this, I might feel differently. The changes that obsoleted Zeev's book prematurely were rather big and necessary, this is small and is for consistency. The fact is that consistency is important for PHP, wether it is studlyCaps or underscores. We just happened to have decided on studlyCaps, if you don't like it then you had your chance to voice this when it was discuss on [EMAIL PROTECTED] We can't continue to open issues every month or two. I agree. But given that its a rather weak argument either way (*), we should respect the extension maintainer's wishes. Georg spent a lot of time writing this extension, and he's expressed his wishes that the extension's OO API remain the same, and provided a valid technical reason, whether people agree with it or not. -Sterling (*) Ie, you have no practical advantage besides consistency. As you know, PHP will never be a consistent language, neither in approach nor in API. That doesn't mean imho one should add more inconsistency lightly, but it s not like MySQLi is violating the pristine mathematical equation that makes up the PHP programming language with dirty thoughts of underscores. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 2004-03-23 at 17:24, Rasmus Lerdorf wrote: Ok, if you are sure of that fine. But lets doublecheck with the authors of the main new components (sqlite, mysqli, simplexml) first and make sure they are all in sync. For example, Derek Ford's simplexml-related message to internals last week(*) worries me somewhat. He passed on what looks to be some basic brokeness in the extension which nobody has addressed so far. Not to add more confusion to the pot, but what of error handling in an object context? Shouldn't non-terminal errors be represented as Exceptions rather than E_ERROR/E_WARNING if calling $sqlite-whatever()? John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Andi Gutmans wrote: Huh? Now you're really going to confuse people. You can always have RC2 and more. Yeah, but changing whole APIs between RCs is just not Ok. I mean, changing those things Before an RC, a la... but it's jut too late now; a lose of face as Georg already mentioned. A lot of people I spoke with already think that we're changing too much things around in even minor releases (though some of those claims are ofcourse bogus), this is only feeding that voice. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, John Coggeshall wrote: On Tue, 2004-03-23 at 17:24, Rasmus Lerdorf wrote: Ok, if you are sure of that fine. But lets doublecheck with the authors of the main new components (sqlite, mysqli, simplexml) first and make sure they are all in sync. For example, Derek Ford's simplexml-related message to internals last week(*) worries me somewhat. He passed on what looks to be some basic brokeness in the extension which nobody has addressed so far. Not to add more confusion to the pot, but what of error handling in an object context? Shouldn't non-terminal errors be represented as Exceptions rather than E_ERROR/E_WARNING if calling $sqlite-whatever()? No, we decided on no internal functions throwing exceptions (DOM excluded). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 23 Mar 2004, Rasmus Lerdorf wrote: they are all in sync. For example, Derek Ford's simplexml-related message to internals last week(*) worries me somewhat. He passed on what looks to be some basic brokeness in the extension which nobody has addressed so far. (*) http://news.php.net/article.php?group=php.internalsarticle=8660 Here's my take on these issues: 1: You can't tell if an element exists or not This one appears to be a real issue, as someone else asked me this exact question earlier today. I can suggest a couple of work arounds, like casting the object to a string and checking if it's empty (gross) or counting the number of elements returned by an XPath query (not Simple). However, this is really the symptom of a more fundamental issue: SimpleXML is not an introspective API. It works great when you know what you're looking for, but breaks down when you're trying to figure out what's there. (For instance, you can't figure out what's the tag name of the root element.) I believe this is somewhat of a conscious decision, but one that may disappoint users. 2: XPath doesn't work with default namespaces I either have or (used to have) a patch to fix this. Due to how XPath handles default namespaces, you need to explicitly associate a prefix with the default URI. Right now, we don't let you do this and it needs to be fixed. This is something that got eliminated during the redesign a few months back and I forgot to add it back. 3: Elements with namespaces aren't referencable. Namespaces are just a bitch in general. I need to double check how this shook out, but I think we ended up forcing people to use the actual namespace URI instead of the prefix because of some nasty issues and edge cases. Rob will know better than I, as he actually coded the thing and all I did was kibbitz. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 23, 2004, at 11:21 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 23 Mar 2004, Rasmus Lerdorf wrote:
they are all in sync. For example, Derek Ford's simplexml-related
message
to internals last week(*) worries me somewhat. He passed on what
looks to
be some basic brokeness in the extension which nobody has addressed so
far.
(*) http://news.php.net/article.php?group=php.internalsarticle=8660
Here's my take on these issues:
1: You can't tell if an element exists or not
OK. So I haven't really looked at this code before, but a cursory
inspection leads me to believe that sxe_prop_dim_exists() doesn't work
right at all for elements.
When you come in testing for the existence of $obj-element, node is
set to the xmlNodePtr for $obj (which exists of course). Then you fall
into this case:
if (elements) {
if (Z_TYPE_P(member) == IS_LONG) {
if (sxe-iter.type == SXE_ITER_CHILD) {
node = php_sxe_get_first_node(sxe, node TSRMLS_CC);
}
node = sxe_get_element_by_offset(sxe, Z_LVAL_P(member),
node);
}
if (node) {
exists = 1;
}
}
I don't see where this actually looks up 'element', it seems like it
simply evaluates the existence of node. I committed a fix, but someone
who knows the code better should validate that it is correct.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Mar 24, 2004, at 12:06 AM, George Schlossnagle wrote: I don't see where this actually looks up 'element', it seems like it simply evaluates the existence of node. I committed a fix, but someone who knows the code better should validate that it is correct. btw, is there a bug number for this? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
The middle case of this dude's example raises a separate concern: count() does not work for objects - it will always return 1. For objects that implement the Iterator interface, it seems reasonable for count() to return a non-trivial answer. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Wed, 24 Mar 2004, George Schlossnagle wrote: On Mar 24, 2004, at 12:06 AM, George Schlossnagle wrote: I don't see where this actually looks up 'element', it seems like it simply evaluates the existence of node. I committed a fix, but someone who knows the code better should validate that it is correct. btw, is there a bug number for this? No, I don't think so. The bug db was down for a couple of days. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tue, 2004-03-23 at 22:46, Derick Rethans wrote: No, we decided on no internal functions throwing exceptions (DOM excluded). So regardless of context, tidy should be doing docref errors? That takes away a lot from an internal object standpoint. I thought a much better approach would be to have the error reflect the context -- i.e. procedural calls would return docref errors, while object calls would throw exceptions. Unfortunately, since there is no way to determine from EG() if you are called from an object context or not (based on conversations with Andi), the implementation is rather nasty. I don't think anyone can make a strong argument against method calls throwing exceptions, so isn't there any way this little detail can be fixed so that all of the internal objects can behave consistently wrt errors? John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hi! Not to start a big flame war here, but if the argument at the end of the day was won for the Let's use studlyCaps for all OO stuff internal in PHP, shouldn't ext/mysqli conform to that? I changed tidy a while ago, and was surprised to see MySQLi has not... Hmm, nobody told me to change it - now it's too late. Maybe we should change it in PHP6. /Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hello Georg, Monday, March 22, 2004, 10:44:09 PM, you wrote: Hi! Not to start a big flame war here, but if the argument at the end of the day was won for the Let's use studlyCaps for all OO stuff internal in PHP, shouldn't ext/mysqli conform to that? I changed tidy a while ago, and was surprised to see MySQLi has not... Hmm, nobody told me to change it - now it's too late. Maybe we should change it in PHP6. Obviously nobody was interested in mysqli OO. Since we are still in pre release we can still change something. So it is up to you to decide. The pro is consitency and the con is work for you :-) marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Monday 22 March 2004 23:17, Marcus Boerger wrote: Hmm, nobody told me to change it - now it's too late. Maybe we should change it in PHP6. Obviously nobody was interested in mysqli OO. Since we are still in pre release we can still change something. So it is up to you to decide. The pro is consitency and the con is work for you :-) I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
and SQLite? On Monday 22 March 2004 23:17, Marcus Boerger wrote: Hmm, nobody told me to change it - now it's too late. Maybe we should change it in PHP6. Obviously nobody was interested in mysqli OO. Since we are still in pre release we can still change something. So it is up to you to decide. The pro is consitency and the con is work for you :-) I agree with Marcus (and I think Andi) here. If its not too much trouble OO interface to mysqli should IMHO follow the same conventions other OO extensions do, Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Hello dv, you may consider me responsible for this mess - i must admit i forgot about sqlite's oo api a long time ago since it is running...(i know lame excuse) Monday, March 22, 2004, 11:57:25 PM, you wrote: and SQLite? On Monday 22 March 2004 23:17, Marcus Boerger wrote: Hmm, nobody told me to change it - now it's too late. Maybe we should change it in PHP6. Obviously nobody was interested in mysqli OO. Since we are still in pre release we can still change something. So it is up to you to decide. The pro is consitency and the con is work for you :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
On Tuesday 23 March 2004 00:13, Marcus Boerger wrote: you may consider me responsible for this mess - i must admit i forgot about sqlite's oo api a long time ago since it is running...(i know lame excuse) Obviously if we're going for consistency (and I thing we should) sqlite oo iterface should be changed as well. Its now or never, and I think there is still time. That of course depends on php5 release master. So Andi your thoughts? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Studlycaps and MySQLi
Not to start a big flame war here, but if the argument at the end of the day was won for the Let's use studlyCaps for all OO stuff internal in PHP, shouldn't ext/mysqli conform to that? I changed tidy a while ago, and was surprised to see MySQLi has not... John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Studlycaps and MySQLi
Yes it should. But I don't know if it's possible to change it at this point (after the RC). It's probably worth it. Andi At 01:11 AM 3/22/2004 -0500, John Coggeshall wrote: Not to start a big flame war here, but if the argument at the end of the day was won for the Let's use studlyCaps for all OO stuff internal in PHP, shouldn't ext/mysqli conform to that? I changed tidy a while ago, and was surprised to see MySQLi has not... John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Andi Gutmans wrote: The facts are the following: a) Existing PHP functions use underscores. PHP's internal *function names* should use _ to delimit between words. b) Some external object models such as Java use StudlyCaps. And this what we should *consistently* adopt for the naming of PHP's internal *method names*. So, of course, I am +1 for studlyCaps. But regardless of a pro/con decision on studlyCaps the result must be consistent. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Sebastian Bergmann wrote: Andi Gutmans wrote: The facts are the following: a) Existing PHP functions use underscores. PHP's internal *function names* should use _ to delimit between words. b) Some external object models such as Java use StudlyCaps. And this what we should *consistently* adopt for the naming of PHP's internal *method names*. So, of course, I am +1 for studlyCaps. But regardless of a pro/con decision on studlyCaps the result must be consistent. Sebastian is RIGHT, but shall consider that not adopting studlyCaps probably will cause inconsistency since some existent object models WONT change. So, as other people said, its not a matter of personal tastes. Defining underscores as STANDARD to OO related code will just create the inconsistency Sebastian told. And the consequenses will be seen in the future, when PHP will have both code using underscores and studlyCaps for OO related code. Someone has doubts it will happen? __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Sat, Dec 06, 2003 at 10:59:33AM +0100, Sebastian Bergmann wrote: PHP's internal *function names* should use _ to delimit between words. [snip] And this what we should *consistently* adopt for the naming of PHP's internal *method names*. Why should methods differ from functions in naming? That in itself is inconsistency... I'm in favour of naming with underscores, simply because that was the PHP way until now and it helps readability a lot. But i guess the only solution that both parties will accept is dynamically removing all underscores from names when calling a function/method (that would clear up the strpos/str_replace etc inconsistency as well). -- Regards, Stefan Walk [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Dec 6, 2003, at 11:58 AM, Andrey Hristov wrote: It's hard but not impossible to extend internal classes. The workaround is to write thin wrappers with the studlyCaps convention which only just call the methods in their parents like INTERNAL_FUNCTION_PARAM_PASSTHRU. After then comes the real class that extends the functionality by extending the wrapper. So if another class extends the latter it does not have to know that the top into the hierarchy is an internal class that uses different naming convention. Anyway, this is an way to workaround, not completely clean but can help. This whole issue is non-technical and purely stylistic. Neither outcome would keep anyone from achieving anything, it may just make life more difficult for the PEAR folks. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
I'm using double-underscores __ to make autoloading of fake packages possible. An example with StudlyCaps: org__phporb__compiler__IdlCompiler With underscores: org__phporb__compiler__idl_compiler I guess the first is better but I can live with the second. IMHO we shouldn't have exceptions. If the DOM extension (and many others) must use StudlyCaps (because of W3C specifications), all OO-based extension or code should use too. We can live with a CS for procedural and other CS for OOP. Cristiano Duarte -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Dec 6, 2003, at 12:40 PM, Stefan Walk wrote: On Sat, Dec 06, 2003 at 11:45:12AM -0500, George Schlossnagle wrote: Why should methods differ from functions in naming? That in itself is inconsistency... I'm in favour of naming with underscores, simply because that was the PHP way until now and it helps readability a lot. This is not really true. In PHP4 there were very few internal classes, so there was not much of a standard for naming class methods. Again, why should method naming differ from function naming? It seems that most of the folks who are siding behind using underscores aren't very interested in using OO code, while the people who are using OOP extensively already support StudlyCaps. My opinion may be biased though. It is. One of the purest OO languages, Ruby, uses underscores to separate words in method names (I have to admit though that constants are named in CamelCase usually.) That's great, but we're not discussing Ruby, we're discussing PHP. No amount of underscores in Ruby effects the fact that PEAR, which is a defacto part of PHP, has standardized on StudlyCaps and has a large amount of code written that way. Huh? That's awful. Who supports that sort of magic? That's not much more magic than case-insensitive functions. I'm not a fan of case-insensitivity. If you propose removing that in PHP5, you'll get my vote (and many others). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 04 Dec 2003 00:42:40 +0200
Andi Gutmans [EMAIL PROTECTED] wrote:
You easily see what is taken from the language and what is user-land
code.
This argument is as non revelant as the aesthetic one.
internal:
class polygon {
function calc_barycenter()
{
}
}
php script:
class mypoly extends polygon{
function calc_barycenter()
{
}
}
$pl = new mypoly();
$pl-calc_barycenter(); // Is it a userland function?
.
any other __objective__ argument?
pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 4 Dec 2003, Pierre-Alain Joye wrote: On Thu, 4 Dec 2003 10:56:42 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: One of the largest cost in software development is maintenance. One key factor regarding maintainability is readability and understandability. These issue cannot be simply dismissed as irrelevant as you try to make it. I have to agree. But that does not match the readability argument told here, as the readability (subjective) enhancement is so small regarding to the additionnal work due to non studlyCaps internal *methods*. I don't see the additional work part here...how is it going to create extra work for the PHP developers? Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 4 Dec 2003 10:56:42 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: One of the largest cost in software development is maintenance. One key factor regarding maintainability is readability and understandability. These issue cannot be simply dismissed as irrelevant as you try to make it. I have to agree. But that does not match the readability argument told here, as the readability (subjective) enhancement is so small regarding to the additionnal work due to non studlyCaps internal *methods*. However I fully agree with you when you say that should be anyway up to the extension maintainers (ie a binder requering _ like mysql). That's why I rather prefer to set a recommandation (to be used by default) and , only if _required_ for easyness/technical reasons, use the alternative naming. Of course, it is always easier to simply dismiss arguments which don't support your point. The price? Your credibility. . pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 2003-12-04 at 05:07, Hartmut Holzgraefe wrote: Robert Cummings wrote: +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen variable name makes all the difference. -1 on that argument as now the CS dictates what names you may chose which should be the other way round IMHO It doesn't dictate what names you may choose, but for those who think IAmAndi lacks aesthetics, then for such people perhaps another choice would have been better. I was merely pointing out that there are plenty of alternate choices thus weakening the argument for blunderscore separation based on the IAmAndi case. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Derick Rethans wrote: haha, with these suckyCaps we have two different styles for core-php functions; that's worse and that's what we *should* care about. +1 And we gain a simple rule of thumb with underscores: underscores = build-in functionality = referr to php.net/function_name study = user supplied stuff = referr to pear.php.net/ or example.com/ Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Robert Cummings wrote: +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen variable name makes all the difference. -1 on that argument as now the CS dictates what names you may chose which should be the other way round IMHO -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 04 Dec 2003 12:09:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Derick Rethans wrote: haha, with these suckyCaps we have two different styles for core-php functions; that's worse and that's what we *should* care about. +1 And we gain a simple rule of thumb with underscores: underscores = build-in functionality = referr to php.net/function_name study = user supplied stuff = referr to pear.php.net/ or example.com/ Absolutely wrong, method overload makes this assumption wrong. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] StudlyCaps
Hey, I think we should come to closure on this discussion because it's becoming hard to catch up with. I'd like to finalize this issue for PHP (the C part) so that we can release Beta 3. I think what PEAR does is really up to the PEAR dev team (although I think it would be nice for them to be consistent with PHP itself). The facts are the following: a) Existing PHP functions use underscores. b) Some external object models such as Java use StudlyCaps. The immediate decision we have to make is if PHP's OOP functionality (class names and method names) use underscores or studly caps. I think for (b) (interfacing with external object models) the answer is obvious. Do what you need to do to expose the external object model, and thus use StudlyCaps where applicable. That's kind of obvious IMO. If the external object model has underscores then use that. However, I think what we do with PHP's object model is not that obvious. Although I'm quite indifferent to these when I program (I usually use the most popular method with the language I'm using) I think there are two advantages for using underscores: a) functions already use them thus we are consistent across the board (something we historically don't excel in). b) StudlyCaps doesn't know how to deal with one character words such as IAmAndi. which would be something like i_am_andi in underscores. You often find yourself having to do two capitol letters one after another and it ruins the whole thing. The same thing happens with acronyms, for example, PHPObject (no differentiation between PHP and Object). I think that even if some OOP developers prefer the studly caps, using underscores might even have an advantage of differentiating between PHP methods and the user's methods. Let's not turn this into a religious war. I think everyone here understands the pros/cons. Let's try and reach a decision quickly and make sure we adopt it, because indecision is worse than making the wrong decision :) I apologize for the long letter. Please don't copy me :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
My vote is on StudlyCaps for class method and attribute names. This is the standard in many OO languages (SmallTalk, C#, Java - as a parenthetical I don't think that SmallTalks adoption of StudlyCaps (one of the first I'm aware of) had anything to do with _ rendering), and while we do not need to mimic other languages, adopting common conventions is a good thing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
