> On Jun 2, 2021, at 4:25 AM, Jordi Boggiano <j.boggi...@seld.be> wrote:
> 
> On 02/06/2021 00:34, Mike Schinkel wrote:
>> But from all this I do agree with you that just returning an array would 
>> likely be acceptable.
>> -----
>> 
>> This would not be a great solution for really large arrays, but then we 
>> can't eliminate the need for a developer to have a reasonable level of 
>> knowledge, right?  So:
>> 
>> $unshifted = $array->unshift($new_element);
>> $shifted = $array->shift();
>> 
>> But, we could also possibly use better names for these:
>> 
>> $right_shifted = $array->shift_right(...$new_element(s));
>> $left_shifted = $array->shift_left([element_count]);
> 
> IMO for unshift() it'd be fine to return a new array, but when processing a 
> list of things in a FIFO pattern I often used array_shift() to get the first 
> "job" out of the array. If $array->shift() returns a new array then how do I 
> access the first item?

That is a really excellent point, something I did not think to consider given 
how rarely I use array_shift().  

But your comment causes me to ponder a number of follow up questions, some of 
which are tangential.  If any reader feels these tangents are worth discussing 
please make another email and quote my relevant comments so we can have a 
dedicated thread for each.

1.) Given Nikita's position that it would only be viable to offer a syntax that 
simulates method calling for arrays if the methods themselves are immutable can 
you envision a solution for allowing  $array->shift() functionality that would 
address getting both element and shifted array without resorting to 
by-reference parameters?

2.) One approach I can envision is to add functionality to PHP that would allow 
the returning multiple values from a function or method — NOT to be confused 
with returning an array that can be destructured with list() or []. There is 
certainly precedence in other languages to prove the validity of the 
programming model, and they solve some thorny issues quite nicely. 

I have wanted to bring this up on the list for eons but have feared not having 
my use-cases written up well enough to keep people from immediately having a 
negative reaction and thus prejudicing too many on the list for it ever to be 
viable. But I am going to risk it and hope this use-case is sufficient to peak 
people's interest, or at least not have them summarily dismiss the idea with 
prejudice.

If PHP were to allow multiple returns then we could have one of the following 
(not sure which would be best):

$element, $shifted = $array->shift();
OR
$shifted, $element = $array->shift();

Following the lead of another language, we could use an underscore placeholder 
to indicate not to capture the return value if we don't need it:

$element, _ = $array->shift();
_, $shifted = $array->shift();

Again, this is NOT the same as array destructuring where the function would 
need to return an array containing the array.

3.) When you have used an array to contain a list of "jobs", are you creating 
that array in your code or have you gotten the array from a function within PHP 
that provides the array such as scandir() or glob()?

4.) Given Nikita's comments on the O(<n>) performance of array_shift() have you 
considered instead simulating a FIFO queue using an array as a stack?  Any 
reason that would not work for your needs?

5.) Alternately given Nikita's comments on array_shift() have you considered 
using SqlQueue: https://www.php.net/manual/en/book.spl.php? It seems a perfect 
fit for your FIFO use-case to the extent you've explained it. Honest question, 
not a challenge.  Wouldn't that work better than an array?

6.) More broadly, this made me wonder about the SPL data structure classes in 
general. I honestly did not think of SplQueue at first because I so rarely use 
any of the SPL classes. I was not until I started to ponder what "different 
data-structure or construction approach" might be appropriate, referencing 
Nikita's comment. Then I wondered why I don't think to use those classes more 
often, and I came up with these hypotheses, in ascending order of likelihood in 
my opinion:

A.) Admittedly superficial but the Spl class names make code look more 
complicated.  I'd much rather see Queue than SplQueue, or more specifically — 
while ignoring the still-raging debate over the best way tonamespace built-in 
PHP classes — I'd much rather use an \SPL\Queue than an SplQueue. Maybe PHP 
could create aliases for these classes but within a namespace?

B.) Out-of-sight, out-of-mind.  I rarely see people use the SPL functions in 
open-source code, discussed on StackExchange, written about in articles or on 
mailing lists.

C1.) The SPL data structure classes do not have anywhere near the functionality 
that arrays have built-in functions for, such as: array_combine(), 
array_fill(), array_map(), array_reduce(), array_slice(), array_splice(), 
array_search(), array_filter(), array_walk(), etc. etc. Maybe PHP could add 
more of that kind of functionality for these data structures?

C2.) Also there are no performant ways to convert one related data structure to 
another.  You can't easily convert a SplStack to a SplQueue, or a SqlQueue to a 
SplPriorityQueue, and there may be other appropriate conversions that PHP 
obviously does not provide.

D.) Few if any built-in PHP functions or methods accept instances of these 
classes as parameters, nor return instances of these classes. Examples include: 
sort(), file(), glob(), scandir(), iterator_to_array(), str_split(), 
str_replace(), preg_match_all(), str_getcsv(), fputcsv()/fgetcsv(), 
func_get_args(), call_user_func_array(), implode()/explode(), sprintf(), 
file_put_contents(), var_dump(), var_export(), filter_input_array(), 
mysql_fetch_row(), get_defined_constants(), get_defined_vars(), 
debug_backtrace(), etc. etc.  So if you are always being handed an array, no 
wonder you rarely ever use the SPL classes, right?

If we were to address any or all of A-to-D maybe PHP developers would be more 
inclined to use different data-structure and/or construction approaches that 
better fit their use-cases?

So in summary the tangential topics I addressed were:

1.) PHP potentially supporting multiple return values, and 
2.) Renewed focus on SPL data structures.

Again, if anyone is interested in these tangential topics and wants to discuss 
further, please create a new thread and quote my applicable comments from this 
email.


-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to