# sqlite's oo api

- Thread: https://externals.io/message/8723
- Original archive: https://news-web.php.net/php.internals/8723
- Started by Marcus Boerger on 2004-03-23T23:48:17+00:00
- Messages: 7
- 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

---

## #8723 — Marcus Boerger — 2004-03-23T23:48:17+00:00

URL: https://externals.io/message/8723#8723

Hello internals,

  after SQLite's commit ~16hours ago i was reminded that i have violated
vertain rules - not change something while in release process and not
changing api's of non experimental extensions.

  I must admit i knew this before but i was in a conflict and i am still.
The conflict is i want consistency and there was a decision for studlyCaps.
To honor the rules more or less i first contacted the relevant ppl in private
and the majority agreed to the change (so i didn't rally wait to hear all).
Obviously i was a bit too hastily here. But i only started to workout the
change because SQLite's OO API was never released other than in RC1 - and
well that it was released like it was is of cause my failure as mentioned
already.

  As you know my actings started a long discussion and now i am questioning:
Are we following our rules and decisions? And if so which rule/decision do
ppl want me to follow? The one i did which potentially hurts some article
writers? Or the other one which would lead to a revert and inconsistency?

  For the moment my decision is to revert await the outcome of the ongoing
discussion. Asked as one of the maintainers i still want the studlyCaps for
consistency. Asked for PHP i also want the studlyCaps. It was a big mistake
not to change the api right after the decision - as i said my fault.

Sorry for the inconvenience
Best regards,
 Marcus


The full diff to get SQLite in studlyCaps fashion can be downloaded here:
http://marcus-boerger.de/php/ext/sqlite/sqlite-oo-api-studlycaps.diff.txt

---

## #8724 — Rasmus Lerdorf — 2004-03-24T00:30:58+00:00

URL: https://externals.io/message/8723#8724 · In reply to: #8723

My take and a bit of a clarification for Andi.  I wasn't criticizing you
personally, I was criticizing the Release Manager which happens to be you.  
Admittedly the distinction is subtle.  The RM's job is to heard cats.  
You take input from everyone and make a decision on when to freeze and
when to release.  After a freeze you fend off people who want to sneak in
changes that are not obvious bug fixes.  If someone convinces you that a 
bigger picture change is required, then you have a problem and I don't 
think just quickly squeezing that change in and pushing out a new release 
before too many people have downloaded the previous release is the right 
solution to that problem because we need time to figure out the 
ramifications of such a change.  For example, how many PEAR packages might 
we break with this?  Are any of them perhaps even in the php5 tarball 
itself?

On the Studlycaps issue my opinion is that it is a guideline and while it
would be nice to have consistency in the end it is ultimately up to the
extension authors to decide whether they wish to follow the guideline or
not.  I have no plans on going back and breaking the few extensions I have
written that have OO APIs because I don't think aesthetic changes is worth
breaking BC over, but I will probably follow the guideline for new ones.

We could make the decision that we will not bundle any extension that
doesn't follow the guidelines although in this case that might not be a 
good idea.  I see 3 ways forward:

1. Stick with the freeze and deal with the inconsistency

2. Remove the freeze, convince Georg to make the change (if possible)
   and make very sure people realize that RC1->RC2 is not just bug fixes

3. Unbundle mysqli to pecl and let it evolve at its own pace and we can
   include it in the standard tarball when everyone is happy with it

-Rasmus

---

## #8725 — George Schlossnagle — 2004-03-24T00:59:39+00:00

URL: https://externals.io/message/8723#8725 · In reply to: #8723

>   As you know my actings started a long discussion and now i am 
> questioning:
> Are we following our rules and decisions? And if so which 
> rule/decision do
> ppl want me to follow? The one i did which potentially hurts some 
> article
> writers? Or the other one which would lead to a revert and 
> inconsistency?

Being concerned about BC before there is an actual release seems silly 
to me.  The whole of PHP5 could be accurately described as 
'experimental' atm.

George

---

## #8736 — Lukas Smith — 2004-03-24T08:15:19+00:00

URL: https://externals.io/message/8723#8736 · In reply to: #8724

Rasmus Lerdorf wrote:
> ramifications of such a change.  For example, how many PEAR packages might 
> we break with this?  Are any of them perhaps even in the php5 tarball 
> itself?

I know this is just an example, but just to clarify:
PEAR is currently taking a bit of a wait and see approach with php5 for 
obvious reasons. We are mainly looking at the BC breaks atm, so there 
are really few packages that have moved to php5 only (afaik only 
PHPUnit2 and SOAP2, which both havent reached a stable state yet). 
Beyond that the biggest problem I can see PEAR facing with php5 are non 
studlyCaps API's since then we have to wrap those API's even if we 
actually just want to extend them, since our CS is studlyCaps.

Beyond that I want to make clear that I am in no position to vote on 
anything on internals@ due to my lack of direct involvement with the php 
source itself.

regards,
Lukas Smith

---

## #8737 — Rasmus Lerdorf — 2004-03-24T08:39:40+00:00

URL: https://externals.io/message/8723#8737 · In reply to: #8736

> Rasmus Lerdorf wrote:
> > […]
> 
> I know this is just an example, but just to clarify:
> PEAR is currently taking a bit of a wait and see approach with php5 for 
> obvious reasons. We are mainly looking at the BC breaks atm, so there 
> are really few packages that have moved to php5 only (afaik only 
> PHPUnit2 and SOAP2, which both havent reached a stable state yet). 

Right, but we aren't just talking about PHP5-only PEAR packages here.  We 
bundle a couple of basic PEAR packages right in the PHP5 distribution 
tarball so we have to be very careful with these and I think also with the 
more common ones that people install.  

-Rasmus

---

## #8751 — Andi Gutmans — 2004-03-24T14:18:42+00:00

URL: https://externals.io/message/8723#8751 · In reply to: #8723

At 04:30 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
>On the Studlycaps issue my opinion is that it is a guideline and while it
>would be nice to have consistency in the end it is ultimately up to the
>extension authors to decide whether they wish to follow the guideline or
>not.  I have no plans on going back and breaking the few extensions I have
>written that have OO APIs because I don't think aesthetic changes is worth
>breaking BC over, but I will probably follow the guideline for new ones.
>
>We could make the decision that we will not bundle any extension that
>doesn't follow the guidelines although in this case that might not be a
>good idea.  I see 3 ways forward:
>
>1. Stick with the freeze and deal with the inconsistency
>
>2. Remove the freeze, convince Georg to make the change (if possible)
>    and make very sure people realize that RC1->RC2 is not just bug fixes
>
>3. Unbundle mysqli to pecl and let it evolve at its own pace and we can
>    include it in the standard tarball when everyone is happy with it

Guys,

We all know that consistency problems in the past have been a pain in the 
ass. I'm sure there have been hundreds of emails on internals@ about these 
issues. All I'm saying is, why shoot ourselves in the foot so early in the 
game especially as we mentioned studlyCaps in the CODING_STANDARDS. It 
doesn't really matter if you like studlyCaps or prefer underscores; 
consistency is the game.
I still think that the right thing to do is to do what's right (change to 
studlyCaps) and release RC2 as soon as possible (whenever everyone is 
ready). We will then restart a deep-freeze for new features and will 
continue to stabilize PHP 5.
But as RM I can't go through every extension in PHP and make sure every 
last place has been changed but extension authors also have to take 
responsibility.
And yes, we'll need to change our articles on Zend.com and we'll have to 
make changes in our PHP 5 book but I think PHP 5 is more important.

Andi

---

## #8752 — David Sklar — 2004-03-24T14:29:29+00:00

URL: https://externals.io/message/8723#8752 · In reply to: #8725

George Schlossnagle wrote:
> 
> Being concerned about BC before there is an actual release seems silly 
> to me.  The whole of PHP5 could be accurately described as 
> 'experimental' atm.

+INF

Everyone who is using PHP5 right now knows (or plausibly should know) 
that it is experimental. Even the text accompanying the RC1 announcement 
says that it is for "playing with" and is not recommended for 
mission-critical use.

Making "BC"-breaking changes now affects a (comparative) few 
experimenters. Leaving things as potentially confusing or inconsistent 
affects the hundreds of thousands (millions?) of people who will use 
PHP5 in the next 5 years.

David