Hi, could you rename these functions to:
cli_process_set_title cli_process_get_title http://www.php.net/manual-lookup.php?pattern=set_&scope=quickref gives me a lot of hits like: xml_parser_set_options stream_set_read_buffer pg_set_info ps_set_border_color etc. its also a lot more readable as it is: object_action_subject. Am 2013-02-07 20:59, schrieb Keyur Govande:
Addressing a bunch of comments at once: 1) I've removed is_available and renamed the set/get methods to: cli_process_title_set/get. I've also removed the test dependencies on pcntl and posix. The patch is updated: https://gist.github.com/keyurdg/4728770 2) Updated the RFC's introduction section with more concrete details about why this is necessary In terms of doing this as an extension: the RFC addresses why this isn't possible. For folks who will not be using this feature, at worst they'll loose a few KB of memory: the amount needed to store the original argv and the original environ. On Thu, Feb 7, 2013 at 1:25 PM, Nikita Popov <nikita....@gmail.com <mailto:nikita....@gmail.com>> wrote: On Thu, Feb 7, 2013 at 2:39 PM, Christoph Rosse <cro...@2bepublished.at <mailto:cro...@2bepublished.at>>wrote: > why wouldn't this go into core? setting the name of the current > php-process is definitely something everyone that develops php-cli scripts > could use. > I use a lot of php-cli scripts and I've never seen the need. Without having hard data to back this up, I am pretty sure that this applies to nearly all php-cli scripts. > We should not base the decision of putting something into the core on > assumptions on how many people are going to use the feature. > Obviously we should. Whether people will use it is pretty much the most important aspect for deciding whether or not something should be added. Even a trivial addition is a loose for the project if nobody is going to use it. And this is no trivial addition. This seems to be quite a bit system dependent and uses some odd methods like overwriting argv memory. And on that note, it also has to copy the argv data if I got that right, which is something it has to do always and not just when people are actually using the feature ;) I'm not saying I'm against this feature. I'd just really appreciate it if we could drop the good old "it doesn't matter if people are going to use it" non-arguments and instead provide a bit more info for people like me, who are not in the process-title-hacking business. I.e. what this is needed for an why this is needed in core. E.g. what Arvid mentioned, that this is useful when you are running many PHP-based daemons and want to distinguish them. That's the kind of stuff I'd like to see in the RFC. Regarding core/non-core. People mentioned that this is not implementable as an extension. That can be either solved by putting it into core or by adding the necessary API hook ;) [I'm not arguing which variant is better, just saying that not being implementable with current core does not mean that we can't make it implementable :)] Thanks, Nikita
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
