Regarding PHP6, string/array APIs View as Markdown

Stas made a good point about need to start with new API, which then can be followed by syntactic sugar.

So, we need some ideas to start with:

1. A lot of people told, that it would be a good idea to come with a written standard regarding arguments order. I don't care what it will be, as long as it will be documented.

2. It would be really useful to have 2 versions of each function: one which mutates the variable and one which returns the new variable.

Example:

<?php
  $src = 'SoUrCe';
  $result = lowered($src); // $result == 'source', $src == 'SoUrCe'
  $result = lower($srd);   // $result == true,     $src = 'source'
?>

3. Speaking of implementation… Functions, which return slice of string/array could be made to reference the same memory-areas as the source strings/arrays. That is until the first modification, of course. Kinda advanced copy-on-write semantics. I know something like that is implemented in D http://dlang.org/d-array-article.html and Go

4. casting between strings and arrays of characters would be a great thing to have too. this way, useful array-oriented functions could be applied to strings

Hey all,

So I've been thinking about this for a while. Here's what I've come up with:

1. We want to maintain loose typing, so implementing a different API on
   string than on int types would be bad.

2. We want to retain backwards compatibility to some extent with the legacy
   API.

3. We want the ability to simplify the standard library.

So here's my thought. Make $var->method($arg1, $arg2) on scalar types a
"short-hand" for \php\method($var, $arg1, $arg2).

So we re-organize the base API into \php, cut down to just the base
methods. So:

\php\length()

• If array, count(), else strlen()
  \php\substr()
• Treat as string always
  \php\replace()
• Normal str_replace semantics
  \php\split()
• Treat as string always
  \php\join()
• Treat as array always
  \php\shuffle()
• If array, array_shuffle, otherwise str_shuffle
  \php\pos()
• if array, array_search(), else strpos()
  \php\reverse()
• if array, array_reverse(), else strrev()
  \php\merge()
• If array, array_merge, if not, string concat
  \php\type()
• return type information about variable
  etc

Now, those that are clearly type specific, or are too specialized to belong
on a "global" type, would then be sub-namespaced:

\php\array\map()
\php\array\keys()
\php\math\min()
\php\math\max()
\php\math\round()
\php\string\number_format()
\php\string\chr()
\php\string\ord()
etc.

The benefit here, is that user types can implement the same "core"
interface and be used polymorphically with the core types (for at least the
base API). So then, countable() would disappear.

Now, there's one more thing that needs to happen. If you call
\php\length($var) directly (procedurally, not as a method call), we'd need
to check if $var is an object that implements ->length(), and if so, call
to that instead of an error.

That's the base idea. It could be extended further to include true objects
for scalars, which would implement the rest of the core API. So, you could
do:

(new \php\Array($array))->keys();

This would then assume standard object semantics for the "wrapped" type,
while at the same time losing the dynamic typing ability of the language
(but it's done on purpose here to keep the API clean).

For BC, we'd need to modify zend_parse_parameters to extract the array from
a wrapped array object, to keep BC code functioning correctly in either
case, but it should be pretty transparent to the user which is passed...

Is it perfect? Absolutely not. But it tries to get around the BC breaks, as
well as the dynamic typing issue that ints can be strings, and vise versa.

Thoughts?

Anthony

Hi!

2. It would be really useful to have 2 versions of each function: one
   which mutates the variable and one which returns the new variable.

Example:

<?php $src = 'SoUrCe'; $result = lowered($src); // $result ==
'source', $src == 'SoUrCe' $result = lower($srd); // $result ==
true, $src = 'source' ?>

I'm not sure I understand why. What's wrong with $src = lowered($src);?

That's just convenience. matter of readability.

lower() can be implemented in userland and if we had "standard" userland library that would be a good place for it :)

function lower(&$str)
{
$str = lowered($str);
}

Also, when lower() returns not true? If there's a legitimate situation
when it must return not true (I can't think of any, but maybe for more
complex functions there is) what lowered() is supposed to do in the same
situation? If there's none, why bother returning true?

As you said, it might be needed in more complex functions and it makes sense to return true just for consistency.
Other option is to (implicitly) return null and use exceptions.
And I, personally, would prefer exceptions ;)

3. Speaking of implementation… Functions, which return slice of
   string/array could be made to reference the same memory-areas as the
   source strings/arrays. That is until the first modification, of
   course. Kinda advanced copy-on-write semantics. I know something like
   that is implemented in D http://dlang.org/d-array-article.html and
   Go

Strings are not modified in PHP (IS_STRING zvals can be modified but the
actual string buffers aren't) so there's no actual "write" and thus no
copy needed. But having this would require separate refcounting on
string values, which may be a bit complicated to do.

much worse than that. refcounting on string-slices!

4. casting between strings and arrays of characters would be a great
   thing to have too. this way, useful array-oriented functions could be
   applied to strings

We already have it, it's str_split().

I know. But that is not "casting". I can not pass string to the function which expects array (thinking about array_map, array_filter, …). I have to call str_split explicitly.