Hacker News Reader

Comment by chez17 | Hacker News Reader

As a PHP programmer the inconsistency of the string functions is not only bothersome, it's embarrassing. This seems like an interesting fix for that.

View on HN

As a PHP programmer the inconsistency of the string,array,regex,et al functions is an occasional annoyance blown way out of proportion, typically by developers who don't even use the language. The horse is dead, continuously beating it is tedious and avoids the elephant in the room, mainly that for the tasks it was invented to handle it still (despite all it's innumerable and interminably cited warts) serves more pages than any other language with no real change on the horizon. You want to gripe about something? Let's talk about Drupal's internals, or better yet, JavaScript.

I think trying to cast stones at JavaScript from PHP land is foolishness, but I agree with your assessment of the PHP string function situation. This project seems to produce PHP code that is an order of magnitude uglier than ordinary PHP. (No mean feat.)

Why not simply implement a nice string class wrapped around ordinary strings with consistently parameterized chainable methods? The resulting code would be cleaner and more idiomatic (in a good sense). I don't think the "win" from doing this is worth the bother (unless maybe UTF8 support were managed as well).

Written much JavaScript without the benefit of jQuery?

I have, actually, and straight Javascript actually isn't so bad for modern browsers, given document.querySelectorAll, etc. jQuery, at this point, is some pleasant syntactic sugar and a whole bunch of backward-compatibility hackery.

But if you're asking about writing JS without jQuery and including support for old browsers (which I've also done), then fair's fair: you have to support PHP4 (which came out about the same time as IE6), and you don't get anything other than the standard library either.

For a non-trivial app, I'm not sure which of those is less pleasant.

Tons.

I've also used JavaScript to automate Adobe's products, extend Cheetah 3d, build web apps in node.js, and develop games in Unity 3d. JavaScript is far from perfect, but it's a nice language.

Note that jQuery is great for fixing problems in the DOM APi, but it doesn't fix JavaScript (which has its own problems but no more than any other useful language). Much of jQuery is obsolete in modern browsers — events are handled fairly well in most browsers, and QuerySelectorAll replaces jQuery for most lookups. I don't like jQuery's iterators, but writing better ones is quite easy.

PHP's problems are with its libraries (themselves far more horrible than the DOM API) and also the language itself. I do find PHP useful but its problems far outnumber JavaScript's.

jQuery seems more like an API to talk to the DOM than an extension or wrapper around Javascript itself. JS simply doesn't reach the same depths of madness and ineptitude as PHP does at the most fundamental levels of the language. Even if it's still fairly insane compared to languages that are actually kinda elegant.

This doesn't fix that, it just makes it worse.

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()

...

......

.........

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.

string: haystack, needle array: needle, haystack

Beyond that, many of the functions take their ordering from their C counterparts.

Getting to know this convention a while ago has made a huge improvement in how I code PHP. I never really knew what the order for haystack / needle parameters were before I read this. Now it's easy to remember.

Reply on news.ycombinator.com