5

UPDATED
Is there any way to force case sensitive function names in PHP, even if it means re-compiling PHP?

  • could this be achieved by some setting in the php.ini?
  • is it possible to achieve this by using some form of name-space "hack"?
  • as a last resort: how (and where) do I edit the PHP C/C++source-code that could force global case-sensitivity --and make it available as an option in the php.ini -which could be overridden by apache config, and .htaccess, and during runtime with ini_set() ?

There are plenty answers that confirm:

  • PHP function-names and class-names are NOT case-sensitive
  • PHP constants and variable names ARE case-sensitive

This question is about taking control of the situation as it is quite painful if you have the following problem:

<?
    define('List', ':List:');
    die(List);
?>

Parse error: syntax error, unexpected ')', expecting '('

In the example above, the "intrinsic" function-name list interferes with the "user-defined" constant List and not in a "good" way - as it results in a Parse Error.

I know many PHP developers do not care too much about "case-sensitivity" and do not see the need for this; however, if you're building a neat boiler-plate, or a framework with well defined data-types as short words (for comparison reasons), then it is a problem as you are targeting a large audience.

Any input would be appreciated, thanks.

  • 4
    A note maybe, [list is a language construct](http://php.net/manual/function.list.php), that's why you get that error. If it were really a function, die would output the value of the constant. demo: https://3v4l.org/88kO2 [reference](http://php.net/manual/reserved.keywords.php) – Yoshi May 08 '16 at 11:46
  • Good point. Still though, it would have been really great if PHP had a INI setting that handles global case-sensitivity. This could be backwards compatible with older versions. –  May 08 '16 at 11:51
  • 1
    I understand, and honestly, I'm with you. But I don't see it coming anytime soon. PhpStorm for example as a code-inspection setting to mark function names with invalid case. In the end, I think, currently it's the IDE that needs to take responsibility. The language won't help. – Yoshi May 08 '16 at 11:54
  • duplicate: 'Before marking this as "duplicate"', 'this question is about taking control of the situation' - That's the same as [Can I make a function case-sensitive in php?](http://stackoverflow.com/questions/28328574/can-i-make-a-function-case-sensitive-in-php). An answer can be found in [Are PHP functions case sensitive?](http://stackoverflow.com/questions/5643496/are-php-functions-case-sensitive). See the accepted answer. – Pinke Helga May 08 '16 at 11:57
  • 1
    Nevertheless a nice, well formed question and justified criticism. – Pinke Helga May 08 '16 at 12:01
  • Hang on, it's not the same as "forcing" though. As a drastic measure one could always edit the `C`/`C++` source-code and re-compile PHP as your own version... Just saying, PHP is open-source, so with a little clever logic one could achieve the impossible. I just don't know how, hence the question :) –  May 08 '16 at 12:02
  • 2
    Not sure about the license, but if legal, you should start a community developing a fork. ;-) Also throw away many of the old functions and make naming and parameters homogeneous. Get rid of functions at all and consequently rely on OOP. – Pinke Helga May 08 '16 at 12:06
  • 1
    In order not to be duplicate you could turn your question into something like "How could I recompile PHP to implement case sensitive function syntax?" – Pinke Helga May 08 '16 at 12:17
  • 1
    imo, the issue with PHP functions, is not just the names of 'em, but the inconsistant order of the parameters. Now, if that was fixed I suspect PHP would be an excellent tool rather than a 'very good' tool as a 'get it done' computer language. As an example see 'Arrgh'? p.s., I really like PHP :) – Ryan Vincent May 08 '16 at 15:41
  • @RyanVincent :: Indeed. For the very same reasons I think I have a "love/hate" relationship with PHP... I guess consistency was not part of the language spec; even so, PHP is popular and handy for anything web-app-related, but, as with anything: "the right tool for the job" is relative. –  May 08 '16 at 15:53
  • 1
    " if you're building a neat boiler-plate, or a framework with well defined data-types as short words (for comparison reasons), then it is a problem as you are targeting a large audience." yes and having to compile a fork to use a reserved keyword is totally something a large audience is going do instead of just not using the framework. – PeeHaa May 08 '16 at 16:02
  • @PeeHaa :: good point :) - see the answer below –  May 08 '16 at 16:04
  • 1
    @RyanVincent (&Steynberg) - I don't know how to start a chat... this could become a nice discussion, but somehow OT. The language spec had been "simple template system". There was no real concept. Then it got more populate and features was requested. Old non binary/encoding safe functions became "famous" and was heavily used. The policy was compatibility, so overaged function has found their way into newer versions. In PHP7 some legacy issues has been cleaned up, however, imho not strict enough. I wouldn't feel wrong with it, if I had to adapt wide parts of old code to a new cleaner version. – Pinke Helga May 08 '16 at 18:06
  • 1
    "The language spec had been "simple template system"" What language spec? We've only had a somewhat official lang spec since 2014 – PeeHaa May 08 '16 at 20:06
  • @PeeHaa :: good point, PHP was not meant to be a programming language, but was forced to remain more-or-less constant by popular demand. –  May 08 '16 at 20:21
  • To the "ARMCHAIR CRITICS" -- if you DOWN-VOTE -then SAY WHY, .. ffs, I've spent a year to gather a little points and all you do is vote it down. If you have nothing constructive to say, then - shut the hell up - and save the down-voting to posts that actually deserve it! ..bloody hell. –  May 08 '16 at 20:24

1 Answers1

2

Finding clues on the net on how exactly to do this seems illusory; however, the following may be useful for anyone looking for clues in achieving something related.

To modify & compile the PHP source-code, see this article:

How to modify the php source code and recompile it?


Here's a few pointers that may be useful:

  • download the PHP source-code from here: http://php.net/downloads.php
  • have a look in the main "engine" folders for files that reference sensitiv & case_ in their contents; however, it is likely in here: ./Zend/zendAPI.c (citation needed)
  • take note of the constant CONST_CS and its value, defined in ./Zend/zend_constants.h file as it is used frequently
  • edit what you see fit, compile the updated code and copy+paste the necessary components into your main PHP runime folder, (in linux it is most likely in: /etc/php

To make your changes be configurable in php.ini

  • you will need to edit the ./Zend/zend_ini.c file
  • add your setting as a function in there
  • make sure it's defined & referenced where necessary, as in the ./Zend/zend_ini_scanner.* files.

To make your changes be configurable in Apache config & .htaccess


Question specific

The above may be helpful for re-building PHP, but, there may be a better and much quicker solution.

Constructive criticism
Related to the nature this question specifically, editing & re-compiling the source may be overkill. Not only is it completely out of "PHP language" scope, but mentioning that this is targeted a large audience may defeat the purpose of the framework / boilerplate entirely.

A better approach
The exact reason for why it is so crucial for case-sensitivity of these exact data-type constant words is unknown; however, maybe re-naming them, or defining functions to use in stead of constant comparison could be beneficial, so:

  • instead of the word: List, how about ListDT (for List-Data-Type)
  • comparison may be longer to type than a short function like: isList()

After all: "speed of coding" could be more important than "speed of code" in many cases.

This approach may prevent the need for re-compiling PHP and the "target audience" won't need to manually obtain and install a very specific PHP version just because "the framework" demands some specific words.

Community
  • 1
  • 1
  • 4
    The whole gist of your problem is that you tried to use a **reserved keyword** for your code. Recompiling php and going on about case sensitivity isn't the solution. Bearing in mind what reserved words are, using namespaces / class constants - those are the tools you're after. TL;DR: you can't use `list` in any form. Yes, it sucks, but it's such a minor limitation for an intelligent person that it doesn't even deserve more than a few seconds of thinking before solving it forever. – N.B. May 08 '16 at 15:22
  • yup, there are quite a few of those "functions that are not really functions". As mentioned here with `list` specifically: http://php.net/manual/en/function.list.php –  May 08 '16 at 15:27
  • 1
    There's around ~70 words you can't use for function names / constants. Here's [the list](http://php.net/manual/en/reserved.keywords.php). If I'm not mistaken, PHPStorm (if you use it) will quickly tell you that you did something wrong by coloring your screen red in case you use one of those the way it's not supposed to be used. I believe you found a workaround, and yes, I tried to use `list` for something too, way way back before. The solution was to concede and simply use word `listing`. Every language has limitations, some more than others, it's important to quickly play around them. – N.B. May 08 '16 at 15:31
  • If anyone thinks the answer above is correct (within reason), remember to up-vote as I won't mark it as correct unless someone thinks it's a good answer, or at least useful in some way, thanks ;) –  May 08 '16 at 15:35
  • This entire question / answer pair is based on a wrong premise imo. Yes it sucks that there are reserved words, yes we all wish to have case sensitive function/method names. Yes `List` is the single worst of them all. But "speed of coding" could be more important than "speed of code" in many cases." is not only very much not true even if it was the case your solution doesn't speed up any coding so the whole argument fails. – PeeHaa May 08 '16 at 16:09
  • @PeeHaa :: what is implied is that mostly developers are racing against deadlines, and simply put: `if (isList($foo)) {...}` is shorter to type than: `if (typeOf($foo) == ListDT) {...}` however, in this case: `if ($foo == List)` is the same character length as in the `isList()` example here; but, ya, not possible. –  May 08 '16 at 16:26
  • Just as a note :: I've spent about 3 hours researching before I posted the answer to the question above, check the post times.. no one answered, so I thought I could share what I found. –  May 08 '16 at 16:30
  • You know that talking about deadlines and typing extra characters doesn't make any sense whatsoever do you? Also wait wat? Where does `isList` come from? Why can't you use it? – PeeHaa May 08 '16 at 16:39
  • @PeeHaa :: logically, typing more characters is more prone to human error, especially when you're in a hurry; and - the longer your function-names, variable-names, etc are, the less line-space you have on a single line -for conditions & arguments. Also, short & uniform character length names renders neat code - for yourself and others to maintain your code. –  May 08 '16 at 16:46
  • @PeeHaa :: You can use `isList()` - when you've defined it yourself. I was saying we can't use `List` as a constant for comparing things. –  May 08 '16 at 16:52