4 ms·
Looks neat. Although I doubt that "hacks" like this will become popular among PHP users any time soon, a proliferation of similar hacks might give the PHP core
by kijin 14y ago
Looks neat. Although I doubt that "hacks" like this will become popular among PHP users any time soon, a proliferation of similar hacks might give the PHP core devs some ideas about how to clean up the language in the next few major versions. PHP could introduce a native object-oriented way to interact with built-in types in PHP 6, just like they did with SPL in PHP 5. Then, in PHP 7, they would deprecate the old functions, and in PHP 8, finally remove them in favor of the new style. After all, new major versions are for backwards-incompatible changes, right? The whole cycle might take a decade, but it would be worth it.
Anyway, here are some suggestions.
1. "echo 'error message' and exit" isn't a particularly elegant solution, and in fact symbolizes everything that is wrong with PHP. What about throwing an exception instead?
2. The ability to specify the charset at object creation and convert to another charset later would be quite helpful, because nobody can remember all those mbstring functions. s('str', 'EUC-KR')->convert('UTF-8') maybe?
3. Why is O.php checking whether magic quotes are enabled? Since you're not even touching GET/POST variables, magic quotes have nothing to do with your library. Are you going to throw an error every time you discover suboptimal settings in the user's PHP environment?
4. Don't modify session settings until the user calls session_start(). They might not want to use your session handling functions, only your string and array functions. Simply including the script should have as few side effects as possible. This helps integration with existing apps.
5. Some of the methods that I'd really love to see in the string class are startsWith(), endsWith(), and contains(), copied straight from .NET. It sucks that I have to do strpos() === FALSE every time I want to check whether a string contains another string, or !strncmp($a, $b, strlen($a)) every time I want to check whether a string starts with another string.
6. While we're trying to clean up PHP's API, why not merge the case-sensitive and case-insensitive versions of string functions into a single method with an optional flag? This is another area where the API is terribly inconsistent, what with 'i's thrown in at random places and sometimes even 'case' to denote the case-insensitive version.
EDIT: Related to 5 and 6, I wrote a similar library back in 2010 for fun, which I put online just now [1]. It doesn't use the clever iterator interface that you incorporated into your library, but I do think that my method names make more sense.
[1] https://gist.github.com/kijin/4736544 https://gist.github.com/kijin/4736544
- raylu 14y agoand sometimes even 'case' to denote the case-insensitive version. To be fair, that's copied from libc (and a lot of the other naming in the string library too): http://linux.die.net/man/3/strcasestr http://linux.die.net/man/3/strcasestr
- apendleton 14y agoThis is probably overly cynical of me, but I feel like a lot of what's keeping PHP alive at this point is inertia, and if some major version ahead required that literally every standard library call be differently expressed (and by consequence, every PHP app essentially be rewritten), the case for continuing to use the language would get weaker than I think it already is. At that point, why not jump ship for something more powerful/performant/whatever?
- robryan 14y agoHow about developers? I know this isn't a problem for the lastest hot startup but business would have teams of people that are well versed in PHP. Sure they probably could change languages for a new project, for a new app to join a group of PHP apps it makes a lot of sense to keep the same language. Personally I am unsure who drives contributions these days, is it individuals/ hobbyists/ small companies or is it being driven by large companies with large existing PHP codebases?
- kijin 14y agoLarge code bases are rarely rewritten from scratch. They evolve over many years, and over time, old code gets replaced with new code, piece by piece. If a language evolves over a similarly long time span (10 years or more), and new features are adopted gradually, I don't see why a backward-incompatible change would require anything more than the usual amount of change when the last of the old code is retired. Call it inertia if you want, but this looks to me to be a good thing if you have a large code base to maintain.
- Joeri 14y agoAuthor here. Because O is currently designed to be the first thing code starts with, for green field programming, there was nowhere for the exception to throw to. Hence the exit. Magic quotes are being checked because I have some ideas for how to improve the PDO API to prevent SQL injection. Those ideas have yet to turn into code for O though. I've been contemplating turning this experiment into a usable library for production code, which would mean splitting it up into constituent parts, and making O.php a container for those parts. Then the separate parts could be used in isolation. I suspect the string and array handling by itself would be quite useful even in established projects, and it seems people here agree. Will start working on that. Thanks for your suggestion about character set conversion. That would be a good addition. I'll add it.