# studlyCaps conclusion

- Thread: https://externals.io/message/8778
- Original archive: https://news-web.php.net/php.internals/8778
- Started by Wez Furlong on 2004-03-26T15:01:19+00:00
- Messages: 2
- 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

---

## #8778 — Wez Furlong — 2004-03-26T15:01:19+00:00

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

<sarcasm>
Lets create an engine level option, lets calls it "coding_convention".
The default is "studlyCaps".

Consider the following code:

$foo->fooBarBaz();

When coding_convention=studlyCaps, the engine will resolve the method
thus (psuedo code):

if (!method_exists($obj, $methodname)) {
    $tmp_method_name = convert_to_underscored_name($methodname);
    if (!method_exists($obj, $tmp_method_name)) {
        error("undefined method $methodname");
    }
    $methodname = $tmp_method_name;
}
$obj->$methodname(...)


When coding_convention=underscores, the engine will resolve it thus:

if (!method_exists($obj, $methodname)) {
    $tmp_method_name = convert_to_studly_name($methodname);
    if (!method_exists($obj, $tmp_method_name)) {
        error("undefined method $methodname");
    }
    $methodname = $tmp_method_name;
}
$obj->$methodname(...)

For the speed concious, there will be a configure option to either
remove the coding convention checks completely.


This approach will keep allow us to keep whichever coding style
we end up deciding on (although I suspect we won't reach a decision
until PHP 7), while meanwhile allowing the end user a transparent
choice of their preference for PHP methods.
</sarcasm>

Let's stop arguing about this stuff--we all have MUCH more important
things to do with our time.

My point of view on this:

- The guideline is to stick with studlyCaps for OO extensions for
  consistency with PEAR.

- New OO extensions SHOULD try to follow the guideline, but are not
  required to (no need to create more work for our limited developer
  resources).

Now, if the authors/maintainers of an OO extension want to change to
studlyCaps, let them do so (I have no objection to SQLite OO api being
changed), but lets not force people that otherwise have no time and
have spent a lot of effort over a long period of time (eg: Georg) to
rewrite their extensions. [keep in mind that one of the reasons that
mysqli was written the way it is to keep it closer to the native
library API; changing that is just re-introducing a nightmare for the
maintainer.]

I've said my piece; lets get over it and get on with it.

--Wez.

---

## #8781 — Andi Gutmans — 2004-03-26T15:32:13+00:00

URL: https://externals.io/message/8778#8781 · In reply to: #8778

I pretty much agree with Wez. A bad decision is worse than no decision :)
The way I see it, studlyCaps has been in the CODING_STANDARDS *and* 
precisely because people and PEAR use them for method names we should go 
with studlyCaps. It would suck to have user-land and internal methods look 
differently. Personally I think it makes sense to keep underscores for 
functions and I see no problem with them differing from methods as I 
usually use underscores for C code and studlyCaps for C++ code :)
We should go with studlyCaps according to CODING_STANDARDS for all 
extensions. If some extension writer refuses (such as George) then so be it 
and we leave it the way it is (although I would ask him to reconsider for 
the long term good of PHP).

Andi


At 03:01 PM 3/26/2004 +0000, Wez Furlong wrote:
><sarcasm>
>Lets create an engine level option, lets calls it "coding_convention".
>The default is "studlyCaps".
>
>Consider the following code:
>
>$foo->fooBarBaz();
>
>When coding_convention=studlyCaps, the engine will resolve the method
>thus (psuedo code):
>
>if (!method_exists($obj, $methodname)) {
>     $tmp_method_name = convert_to_underscored_name($methodname);
>     if (!method_exists($obj, $tmp_method_name)) {
>         error("undefined method $methodname");
>     }
>     $methodname = $tmp_method_name;
>}
>$obj->$methodname(...)
>
>
>When coding_convention=underscores, the engine will resolve it thus:
>
>if (!method_exists($obj, $methodname)) {
>     $tmp_method_name = convert_to_studly_name($methodname);
>     if (!method_exists($obj, $tmp_method_name)) {
>         error("undefined method $methodname");
>     }
>     $methodname = $tmp_method_name;
>}
>$obj->$methodname(...)
>
>For the speed concious, there will be a configure option to either
>remove the coding convention checks completely.
>
>
>This approach will keep allow us to keep whichever coding style
>we end up deciding on (although I suspect we won't reach a decision
>until PHP 7), while meanwhile allowing the end user a transparent
>choice of their preference for PHP methods.
></sarcasm>
>
>Let's stop arguing about this stuff--we all have MUCH more important
>things to do with our time.
>
>My point of view on this:
>
>- The guideline is to stick with studlyCaps for OO extensions for
>   consistency with PEAR.
>
>- New OO extensions SHOULD try to follow the guideline, but are not
>   required to (no need to create more work for our limited developer
>   resources).
>
>Now, if the authors/maintainers of an OO extension want to change to
>studlyCaps, let them do so (I have no objection to SQLite OO api being
>changed), but lets not force people that otherwise have no time and
>have spent a lot of effort over a long period of time (eg: Georg) to
>rewrite their extensions. [keep in mind that one of the reasons that
>mysqli was written the way it is to keep it closer to the native
>library API; changing that is just re-introducing a nightmare for the
>maintainer.]
>
>I've said my piece; lets get over it and get on with it.
>
>--Wez.