On Wed, Jul 11, 2018 at 11:42 AM Woortmann, Enno <enno.woortm...@web.de> wrote:
>
> Am 11.07.2018 um 18:20 schrieb Levi Morrison:
>
> > As an example, it was claimed:
> >
> >> If I use a function I expect it to give me a return value which I can
> >> use without any further post processing $wantedValue =
> >> fancyFunction($someInput);
> > But this isn't true even for the array_value_* functions. There must
> > be pre or post processing because of error conditions. This was
> > pointed out by myself and others, but it was still ignored.
> >
> > This is what I mean by discarded, not discussed.
>
> In my eyes being aware of what I put into a function and thus catching
> non array inputs and empty inputs before differs a lot from post
> processing return values as it increases the comprehensibility of the
> code. I also can think of cases where the input format is known and no
> further checks are required.
>
> Additionally the tuple return pattern is not common among the PHP core
> functions and I don't know many occurences of this pattern in userland
> PHP code neither at the companies I've worked at nor at open source
> software/frameworks (correct me if I'm wrong) except the by far outdated
> old foreach construct with reset() and each(), thus I assume it's not a
> that common pattern for PHP developers to use it in core functions.
>
> As I pointed out during the discussion we should also watch at existing
> functions with the same problem, differ between a valid return value and
> an error.
> Not all of them can be changed to use different return mechanisms like
> the tuple return pattern (eg. array_pop).
>
> Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later
> stage to not return null in error cases but instead throw an
> InvalidArgumentException or something like that (at least for function
> calls with an empty array for functions which require a filled array,
> for invalid types maybe a fatal TypeError like it's thrown when a type
> hinted argument in a userland function is violated is the correct
> choice). Would be a pretty large BC breaking change but it would be
> consistent among the array functions.
>
> In my opinion neither rejecting the RFC nor changing it to return tuples
> solves the underlying problem.
What is the underlying problem in your opinion?
My opinion is that the core problem is that these functions cannot be
efficiently implemented in userland, at least not the ones that get
the last key and/or value of the array. You either need to make a copy
or traverse through the whole array. I have been working to solve this
by making a bidirectional array iterator that can start at either end
of the array and can traverse back and forth. This work will not ready
for 7.3, not even with the extension to the feature freeze because
there is some design that needs to happen; the work I have so far is
here:
https://github.com/php/php-src/compare/master...morrisonlevi:BidirectionalArrayIterator
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
