Naming Arguments

php.internals

Sara Golemon

20 years ago
That's "Naming" not "Named". From the perspective of providing reflection in general and giving something for editors with code completion to use in specific, would there be an interrest in backfilling the arg_info structs for internal functions (both core and otherwise) with argument naming and type hinting even where it's not technically needed? On the con side, this does add memory usage and processing time for no direct production benefit. Any utility which wanted this degree of introspection *could* parse the XML protos in phpdoc and get the same (or better) information, so it doesn't really gain that much for what it costs. Do please forget about the work required to fill in this information. There are more than enough volunteers to do the grunge work(and frankly it'd be tough for 'em to get it horribly wrong), this is just a question of: "Would there be an interrest in folding this data into the core?" and secondly: "Should new extension writers be encouraged to fill this information in?". -Sara

Jared Williams

20 years ago
> From the perspective of providing reflection in general and > giving something for editors with code completion to use in > specific, would there be an interrest in backfilling the > arg_info structs for internal functions (both core and > otherwise) with argument naming and type hinting even where > it's not technically needed? > > On the con side, this does add memory usage and processing > time for no direct production benefit. Any utility which > wanted this degree of introspection *could* parse the XML > protos in phpdoc and get the same (or > better) information, so it doesn't really gain that much for > what it costs.
Can you produce the arg_info structs from parsing the XML protos?
> > Do please forget about the work required to fill in this > information. There are more than enough volunteers to do the > grunge work(and frankly it'd be tough for 'em to get it > horribly wrong), this is just a question of: "Would there be > an interrest in folding this data into the core?" and secondly: > "Should new extension writers be encouraged to fill this > information in?".
Perhaps some tool to generate boiler plate docbook from introspection would be enough encouragement? Jared

Hartmut Holzgraefe

20 years ago
Jared Williams wrote:
> Perhaps some tool to generate boiler plate docbook from introspection > would be enough encouragement?
we can already generate this from the proto comment lines or you could use PEAR::CodeGen_PECL which generates C code and DocBook at the same time ...
-- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com

Andi Gutmans

20 years ago
At 12:01 AM 1/18/2006, Sara Golemon wrote:
>Do please forget about the work required to fill in this >information. There are more than enough volunteers to do the grunge >work(and frankly it'd be tough for 'em to get it horribly wrong), >this is just a question of: "Would there be an interrest in folding >this data into the core?" and secondly: "Should new extension >writers be encouraged to fill this information in?".
Andrei is waiting for volunteers to upgrade internal functions to Unicode :) Andi

Hartmut Holzgraefe

20 years ago
Andi Gutmans wrote:
> Andrei is waiting for volunteers to upgrade internal functions to > Unicode :)
is there a todo list of functions converted, being worked on, pending?
-- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com

Andi Gutmans

20 years ago
Not sure if there's a list. I think it's 90% or so not converted. Andrei, you can answer this one better than me. At 03:12 PM 1/18/2006, Hartmut Holzgraefe wrote:

Hartmut Holzgraefe

20 years ago
Andi Gutmans wrote:
> Not sure if there's a list. I think it's 90% or so not converted. > Andrei, you can answer this one better than me.
well, the only one i checked so far was my levenshtein() function, and seeing something as esoteric as this already being converted made me think most of the reast was, too
-- Hartmut Holzgraefe, Senior Support Engineer . MySQL AB, www.mysql.com

Steph

20 years ago
Try /unicode_progress.txt. Dmitry appears to have cleaned IS_BINARY references from everything that was already unicoded prior to the Paris meeting. - Steph ----- Original Message ----- From: "Hartmut Holzgraefe" <hartmut@php.net> To: "Andi Gutmans" <andi@zend.com> Cc: "Sara Golemon" <pollita@php.net>; <internals@lists.php.net>; "Andrei Zmievski" <andrei@gravitonic.com> Sent: Thursday, January 19, 2006 2:11 AM Subject: Re: [PHP-DEV] Naming Arguments

Andi Gutmans

20 years ago
If that's accurate than from the 4000 or so functions we have, there are about 3980 to go :) At 04:45 PM 1/18/2006, Steph Fox wrote:

Andrei Zmievski

20 years ago
There is no "unconverted" function list. There is unicode-progress.txt file where we have been tracking what has been done, but I'm not sure as to its accuracy as of yet. Some of the functions listed there may need to be looked over after Dmitry's patch. -Andrei On Jan 18, 2006, at 3:31 PM, Andi Gutmans wrote:

Sean Coates

20 years ago
Andrei Zmievski wrote:
> There is no "unconverted" function list. There is unicode-progress.txt > file where we have been tracking what has been done, but I'm not sure as > to its accuracy as of yet. Some of the functions listed there may need > to be looked over after Dmitry's patch.
It would be nice to be able to track this progress directly in the source via some sort of meta-data. Embedding the "unicode status" in function protos would be ideal. Something like: /* {{{ proto mixed foo(mixed bar) Foos the bar */ Could become: /* {{{ proto mixed foo(mixed bar) U Foos the bar */ Meaning that this function has been tested to be functional under the new Unicode rules.. or "Unicode-safe" Opinions? S