The javascript API is there because it's the only one I can keep remembering, I always forget the exact PHP functions and have to keep the php docs open. There also didn't seem to be any naming collisions, so it is harmless. Having developed some test and demo code on top of it, I've come to realize it feels too alien inside of PHP to actually use, so that part is probably going away.
JavaScript uses camelCase; the C functions use_underscores. Mixing and matching the two has been a complaint about the entire PHP library for a long time.
An interesting thing in a language would be to say that `indexOf` is an identifier aliased to `index_of`. It would means that the choice of the convention would rely on the user of the libraries instead of the API developers (which will never agree on a single notation).
Multiple calling conventions that allow for inconsistent use of functions for a language with multiple naming conventions resulting in already inconsistent code is... not the most fantastic idea I've ever entertained.
It's an interesting idea, but there's only one right answer here.
Sure, I was talking about a 'new' programming language. PHP has already a bunch of work required to fix its own standard library.
The point is, the standard libraries, especially in languages such as C++, Python or Javascript, are far from being the only libraries used by a project. Even if they follow consistent conventions, it can happen that an external library author does follow another convention. Using both libraries can lead to use multiple naming conventions in a single program, which doesn't help readability. It would be nice to be able to prevent this.
This is an experiment in meta-programming PHP to give it a saner API.
Sweet.
s() turns all the standard string functions into methods with identical behavior:
s($haystack)->pos($needle)
OK. Cool. Sounds good.
->preg_replace(), ->in_array()
Yep. Awesome.
The s() function also implements JavaScript's string API:
->charAt(), ->indexOf(), ->lastIndexOf()
...
......
.........