# Repeat question on underscore

- Thread: https://externals.io/message/8940
- Original archive: https://news-web.php.net/php.internals/8940
- Started by Lester Caine on 2004-04-06T08:15:52+00:00
- Messages: 5
- 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

---

## #8940 — Lester Caine — 2004-04-06T08:15:52+00:00

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

I have not had an answer yet so I will rephrase the question.

Not following all the discussions on studlyCaps and their 
adoption, I am having a little trouble understanding the 
implications.

The current php manual has hundreds of functions with 
underscore in the name. Are these all going to be replaced? 
In which case ALL existing script has to be re-written?

If not, just where is the line drawn?

I hope that people can see my confusion.

-- 
Lester Caine
-----------------------------
L.S.Caine Electronic Services

---

## #8941 — Ard Biesheuvel — 2004-04-06T08:17:11+00:00

URL: https://externals.io/message/8940#8941 · In reply to: #8940

Lester Caine wrote:
> The current php manual has hundreds of functions with underscore in the 
> name. Are these all going to be replaced? In which case ALL existing 
> script has to be re-written?

No, studly caps have been adopted as a standard only for method names in 
the OO-style API, not for the procedural API.

-- 
Ard

---

## #8942 — Lester Caine — 2004-04-06T08:45:40+00:00

URL: https://externals.io/message/8940#8942 · In reply to: #8941

Ard Biesheuvel wrote:
> Lester Caine wrote:
> 
> > […]
> 
> No, studly caps have been adopted as a standard only for method names in 
> the OO-style API, not for the procedural API.

Thanks for that.

So it IS something that I will have to take account of when 
I start looking at moving the interbase module to a firebird 
native version. If the interbase module accesses the 
OO-style API. If it does not, then I presume that it may be 
advantageous to handle any required conversions then?

-- 
Lester Caine
-----------------------------
L.S.Caine Electronic Services

---

## #8945 — Ard Biesheuvel — 2004-04-06T10:12:53+00:00

URL: https://externals.io/message/8940#8945 · In reply to: #8942

Lester Caine wrote:
> So it IS something that I will have to take account of when I start 
> looking at moving the interbase module to a firebird native version. If 
> the interbase module accesses the OO-style API. If it does not, then I 
> presume that it may be advantageous to handle any required conversions 
> then?

Interesting ...
I am curious what your motivation is for moving the Interbase module to 
a fb version. Furthermore, the studly caps standard was adopted for PHP 
methods, and not for the C (implementation) level, so this will hardly 
be of influence to extension implementers.

-- 
Ard

---

## #8947 — Lester Caine — 2004-04-06T11:05:02+00:00

URL: https://externals.io/message/8940#8947 · In reply to: #8945

Ard Biesheuvel wrote:

> Interesting ...
> I am curious what your motivation is for moving the Interbase module to 
> a fb version. 

Divergence of the API layers, and I would like to get into 
some of the facilities that are currently not very well 
supported. There is no panic on this which is why I'm happy 
to wait until PHP5 has been released, but it may become a 
problem.

> Furthermore, the studly caps standard was adopted for PHP 
> methods, and not for the C (implementation) level, so this will hardly 
> be of influence to extension implementers.

I've spent a lot more time fault finding with the likes of 
the ADOdb layer, than the next layer down, and currently 
having to live with the inactivity of Borland on Builder VCL 
support, I'm looking to the future. When I see major changes 
taking place I get a bit jittery - I've already lived 
through three rebuilds of my application code base thanks to 
Borland, and so I don't want to back the wrong horse this 
time :)

-- 
Lester Caine
-----------------------------
L.S.Caine Electronic Services