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/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
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/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
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
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
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
and SQLite?
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
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?
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 :-)
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
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
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
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
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
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 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/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
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
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/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
Sure, your book isn't ready yet. Would be interesting to know your
opinion if
it would be printed already.
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
Hello John,
Tuesday, March 23, 2004, 9:05:51 PM, you 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,
Marcus mailto:helly@php.net
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
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
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
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
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