Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Studlycaps and MySQLi »

Studlycaps and MySQLi

php.internals

John Coggeshall

22 years ago
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 Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Andi Gutmans

22 years ago
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:

Georg Richter

22 years ago
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

Marcus Börger

22 years ago
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

Edin Kadribasic

22 years ago
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

Unnamed Person

22 years ago
and SQLite?

Marcus Börger

22 years ago
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:

Edin Kadribasic

22 years ago
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

Andi Gutmans

22 years ago
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

John Coggeshall

22 years ago
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 Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Andi Gutmans

22 years ago
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

Ilia A.

22 years ago
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

Georg Richter

22 years ago
> 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

Edin Kadribasic

22 years ago
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

George Schlossnagle

22 years ago
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

22 years ago
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 Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Georg Richter

22 years ago
> > 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

Chris Shiflett

22 years ago
--- Georg Richter <georg@php.net> 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

John Coggeshall

22 years ago
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 Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Ferdinand Beyer

22 years ago
What about using the old names as aliases for the new ones, triggering deprecation warnings when called?
-- Ferdinand Beyer <fb@fbeyer.com>

Markus Fischer

22 years ago
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 ;) - Markus

Derick Rethans

22 years ago
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

Edin Kadribasic

22 years ago
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

Ilia A.

22 years ago
On March 23, 2004 10:44 am, Edin Kadribasic wrote:
> 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?
Had this been a change of functionality that existed for a short period of time I would agree with your wholeheartedly. However, non-studlyCaps OO interface for SQLite has been around over a year now. Many people were shown examples of this via articles, tutorials and possibly books(?), hence it would only make sense to avoid breaking BC by adding a few aliases. In retrospect, someone could say it is silly to make such drastic changes with no practical benefit this late in the release cycle. Ilia

Christian Schneider

22 years ago
Edin Kadribasic wrote:
> 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?
I agree. Having two names and introducing deprecated names now is pure bloat and maintenance hell. Let people fix all the existing code now, which should be about a total of 100 lines of code in the world. And no, tutorials and books don't count, you don't want them to promote a deprecated API either. They should be changed. Change it now or regret(support) it the rest of you (PHP-)live :-) - Chris

Andrei Zmievski

22 years ago
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

Sterling Hughes

22 years ago
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: