On Mon, May 26, 2014 at 2:20 PM, Bob Weinand <bobwei9@hotmail.com> wrote:
> Am 26.5.2014 um 12:11 schrieb Pierre Joye <pierre.php@gmail.com>:
>> On Mon, May 26, 2014 at 11:39 AM, Bob Weinand <bobwei9@hotmail.com> wrote:
>>> Actually, that's exactly my the original API, just with ZP_OPTIONAL instead of
>>> numbers for counts:
>>
>> Where was it proposed? I missed it.
>
> It wasn't proposed, it just was the initial patch I showed Dmitry when I made a small PoC.
>
>>> ZEND_PARSE_PARAMETERS(ZP_ARRAY(input) ZP_LONG(offset) ZP_OPTIONAL ZP_ZVAL(z_length)
>>> ZP_BOOL(preserve_keys), { return; })
>>> (The return at the end is the error branch)
>>>
>>> I still prefer it that way, but Dmitry doesn't...
>>
>> Pretty much the same to me, with the same conclusion as well, sadly.
>>
>> I do not find it more readable than the one in the RFC and it does not
>> solve the double or sometimes triple declarations of the arguments.
>> And I do not even want to think about how it will look if we implement
>> named arguments (let face it, we will have them).
>
> I highly doubt we can solve that problem. I think of it being impossible.
> (When not trying abysmal things like parsing code upon compiling)
>
>>> It's the most readable I still think.
>>
>> zpp current usage is much more readable to me and less error prone
>> while writing (clang plugin helping to check the syntax, see Johannes
>> tools).
>
> Actually, with the new implementation, you don't even need a plugin for
> checking types etc.. Even gcc does that for you with a nice warning.
>
>> May I point you to my questions in this thread about extending the
>> reflection struct, add the necessary info (types) and maybe do the
>> naming args while being at it?
>
> See above, I think of it as impossible.
Ok, that's impossible. Now let us spend some time on that to figure out why :)
--
Pierre
@pierrejoye | http://www.libgd.org