Michael Shadle wrote:
I'm aware people complain about PHP flaws, but having misc global core
functions for strings, arrays and other data types is a new one.
I am still a purest at heart and don't see the need for namespacing in general.
I am thinking it provides some lower level memory space improvements and less
conflicts, but I feel like if you can't code in global space perhaps you should
be rethinking how you code. I don't think most people care about the lower
level advantages, they're just looking at it from a code laziness perspective.
Why make \bar\baz\foo() or $bar->baz->foo() instead of bar_baz_foo()? Prefixing
functions seems perfectly effective. I see a lot of code that looks like they're
using namespaces or OO just to group things together and organize code in some
fashion. Not because there's any inherent benefit.
I'd much rather see effort taken on renaming functions to be more consistent,
and making needle/haystack consistent, and maybe throw in named parameters. PHP
is getting too complex as it is.
I've been talking to people about this concept for 2-3 years and get
mixed responses about it.
Although my approach is slightly different : instead of just namespacing
existing functions, I'd go the extra mile to resolve the inconsistencies
that PHP has had to live with for so long. So for example :
- str_replace would have an identical function called String_replace (or
\String\replace if you really want to have the namespacing, which
actually wouldn't be required and might even cause conflicts for certain
code already using namespaces with certain names)
- strpos --> String_position with a needle/haystack that's consistent
with String_replace
- etc.
The old functions would remain, so old code still works as before.
Deprecating those old functions could be something for 6.2 or so, with
actual removal for 7.0, meaning it provides people a full major release
to adapt, which is much more gentle than what Python did. Given that PHP
5 is now almost 9 years old, if future major PHP releases follow the
same pace, that should be enough time to declare 10-year old PHP code
EOL ;-)
Additionally, a lot of code could be 'fixed' automatically, since the
functions would be identical, perhaps only differing in the parameter
order, which is not an issue for automatic changes either.
In fact, the concept is not really new. DateTime is probably the best
existing example of such an implementation. We had to live with
date_add, date_create, date_diff and so on, but DateTime provides a
clearer, more consistent approach, one that could be replicated for most
of the other language features.
Pros :
- Clearer naming, obviously.
- Consistency across the board, in names and parameters
- Easier for non-PHP developers to switch to the language. Now many of
them see the mess that function names in PHP is (underscored, not
underscored, with prefix, without prefix, 'to' written as 'to', 'to'
written as 2, etc.) and they instantly turn back
Cons :
- There will be a very small performance hit, since 1 of the 2 will
always be an alias for the other, be it with possible changed parameter
order
- More typing - yes, the names will (usually) be longer. But that's what
auto-complete is for...
- We'll be stuck with 2 names for every function for an entire major
release and the parameter order would be different for some of them.
- Purists will say that we're breaking their language.
PHP purest at heart, (who has code that has lasted for a decade and multiple
major php code changes still did not break it)
I agree that in most cases, that's a good thing. But it's also how we
ended up with a thing called the Y2k problem : stuff running forever.
Disclaimer : I've been developing with PHP since 1997, so I'm very fond
of the language. "If it ain't broke, don't fix it" is true, but I think
we can all admit that on consistency level PHP has been at least badly
damaged from the start. So maybe we need to think about fixing at least
some parts of it.
Don't get me wrong, I know it's not as easy as switching a incandescent
light bulb to a led light bulb, but the hardest job will be deciding on
the names themselves. But if we can find a common ground there (yes,
yes, I'm dreaming), we might finally get a trully consistent set of core
functions in PHP. And although it might not be the most critical
improvement PHP needs, it most certainly would be one we could publicly
brag about.
Just my 2 cents...
Kind regards,
Wim
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
