PHP 6 : a new API ? View as Markdown

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

So why not avoiding this by adding it as methods of the scalar variable instead, aka autoboxing.
This would allow the new api to be closer to what people are used to from other languages, needs far less typing and IDE autocomplete of available functions pr type with "->".

I would also prefer autoboxing, at least for arrays and strings
(unsure about numbers). Would also be cool with some resources e.g. gd
library.