Hey:
Sorry for top post, first.
I am going to talk about a thought I have..
we can reuse the arginfo as the only key struct for function
arguments declaration/parsing..
something like, take strlen as example:
declaring:
ZEND_ARG_INFO(strlen_arginfo, 0, 0, 1)
Z_ARG_STR()
ZEND_ARG_INFO_END();
then when doing register internal function. Zend vm will bind the Z_ARG_STR to
int num_args = 0;
(zend_internl_functions
*)(strlen_function)->argument_handlers[num_args++] =
zend_parse_parameter_str;
the zend_parse_parameter_str here is the handler only handling with
str(which will be effective)
then while in zif_strlen(), only needs call :
zend_string *str;
zend_parser_parameters(stren_arginfo, &str);
the only thing I am not sure now is, if there are more than 1
arguments of one function, let's say it's 5..
this implementation will doing 5 functions call..... which
maybe slower than previous zend_parse_parameter
thoughts?
thanks
On Tue, May 27, 2014 at 10:06 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> 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).
>
> Not really - I have to go to the docs each time to remember what \ or /
> are and what is the difference between H and h or z and Z. And putting a
> wrong arg type is extremely easy. I've just learned about clang thing
> this month, so I'm pretty sure I can count number of people who use it
> on one hand, and it doesn't seem to be mentioned anywhere in the docs.
>
>> 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?
>
> This would be great (again, laying ground for named args support) but
> I'm not sure how to do it. We have a bit of a contradiction here since
> the speedup requires unrolled code (that's what the current ideas do)
> and reflection requires static data struct. I'm not sure how to make
> both work. Maybe with some kind of function pointers in the data struct
> for parsing? But I'm afraid then it would lose the speedup, since it
> won't be inlined unrolled code anymore.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
--
Xinchen Hui Laruence
Consultant at Zend
http://www.laruence.com/