# Studlycaps and MySQLi - Thread: https://externals.io/message/8639 - Original archive: https://news-web.php.net/php.internals/8639 - Started by John Coggeshall on 2004-03-22T06:11:22+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #8639 — John Coggeshall — 2004-03-22T06:11:22+00:00 URL: https://externals.io/message/8639#8639 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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~= --- ## #8641 — Andi Gutmans — 2004-03-22T07:01:36+00:00 URL: https://externals.io/message/8639#8641 · In reply to: #8639 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 Handbook http://www.php-handbook.com/ >-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~= --- ## #8657 — Georg Richter — 2004-03-22T21:44:09+00:00 URL: https://externals.io/message/8639#8657 · In reply to: #8639 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 --- ## #8658 — Marcus Boerger — 2004-03-22T22:17:51+00:00 URL: https://externals.io/message/8639#8658 · In reply to: #8657 Hello Georg, Monday, March 22, 2004, 10:44:09 PM, you wrote: > Hi! > > […] > 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 --- ## #8659 — Edin Kadribasic — 2004-03-22T22:27:08+00:00 URL: https://externals.io/message/8639#8659 · In reply to: #8658 > > […] > > 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 --- ## #8661 — dv@josheli.com — 2004-03-22T22:57:25+00:00 URL: https://externals.io/message/8639#8661 · In reply to: #8659 and SQLite? > > > […] > > 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 --- ## #8662 — Marcus Boerger — 2004-03-22T23:13:15+00:00 URL: https://externals.io/message/8639#8662 · In reply to: #8661 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? > > […] --- ## #8663 — Edin Kadribasic — 2004-03-22T23:55:34+00:00 URL: https://externals.io/message/8639#8663 · In reply to: #8662 > 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 --- ## #8668 — Georg Richter — 2004-03-23T10:58:06+00:00 URL: https://externals.io/message/8639#8668 · In reply to: #8659 > 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 --- ## #8669 — Edin Kadribasic — 2004-03-23T11:52:55+00:00 URL: https://externals.io/message/8639#8669 · In reply to: #8668 > > […] > > 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 --- ## #8671 — George Schlossnagle — 2004-03-23T14:00:20+00:00 URL: https://externals.io/message/8639#8671 · In reply to: #8669 > > > […] 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 --- ## #8672 — John Coggeshall — 2004-03-23T14:09:00+00:00 URL: https://externals.io/message/8639#8672 · In reply to: #8671 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 > > > > […] > > 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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~= --- ## #8673 — Sterling Hughes — 2004-03-23T15:19:16+00:00 URL: https://externals.io/message/8639#8673 · In reply to: #8668 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 > > > > […] > > 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 --- ## #8677 — Ilia Alshanetsky — 2004-03-23T15:36:55+00:00 URL: https://externals.io/message/8639#8677 · In reply to: #8662 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 --- ## #8688 — Georg Richter — 2004-03-23T17:58:57+00:00 URL: https://externals.io/message/8639#8688 · In reply to: #8672 > > 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 --- ## #8699 — John Coggeshall — 2004-03-23T20:05:51+00:00 URL: https://externals.io/message/8639#8699 · In reply to: #8688 > 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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~= --- ## #8700 — George Schlossnagle — 2004-03-23T20:14:07+00:00 URL: https://externals.io/message/8639#8700 · In reply to: #8699 > > > […] My book is on the shelves and things got changed under me (exceptions forced to derive from Exception, a few changes in SPL). Like I said in my previous mail, while it's annoying, it's also to be expected if you write something before a final release. I'll post an errata and fix it in a second printing (or worse comes to worse, in a second edition). In my mind it would be unreasonable for me to be upset at anyone but myself over these things. George // George Schlossnagle // Postal Engine -- http://www.postalengine.com/ // Ecelerity: fastest MTA on earth --- ## #8701 — Marcus Boerger — 2004-03-23T20:15:33+00:00 URL: https://externals.io/message/8639#8701 · In reply to: #8699 Hello John, Tuesday, March 23, 2004, 9:05:51 PM, you wrote: > > > […] > 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, Marcus mailto:helly@php.net --- ## #8702 — Hans Lellelid — 2004-03-23T20:41:26+00:00 URL: https://externals.io/message/8639#8702 · In reply to: #8701 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 --- ## #8707 — Georg Richter — 2004-03-23T21:19:18+00:00 URL: https://externals.io/message/8639#8707 · In reply to: #8699 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 --- ## #8709 — Rasmus Lerdorf — 2004-03-23T21:24:05+00:00 URL: https://externals.io/message/8639#8709 · In reply to: #8707 > 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