Re: [PHP-DEV] Memory warning hook
One should try ext/memtrack http://pecl.php.net/package/memtrack Also ext/memprof https://github.com/arnaud-lb/php-memory-profiler/ Julien.Pauli On Tue, Mar 5, 2013 at 9:14 PM, nat...@starin.biz wrote: This is not the same at all. When are you going to run this code? Memory allocations happen all the time. What Nathan asked for is an event that is triggered when the memory consumption reaches a threshold. However, there is a different solution, which is better IMHO in the case of caches: weak references. A weak reference automatically frees the memory of the object, when the memory is needed. http://php.net/manual/en/book.weakref.php. Having said that, none of these solutions scale up to multiple servers. This is why shared cache systems like memcached are recommended. I agree this probably is a good solution and I personally do use it along with shared memory tools, however there may be cases where the dev may gain more benefit from having a memory-warning installable trigger in place. This would allow things like allowing the dev to release certain cache objects before others or something completely different that I have not thought of yet. Running the GC is most likely faster than most cleanup routines a user could run, also usually there is not that much stuff cached in PHP scripts. If a PHP script has tons of data, which it can easily throw away, in memory this sounds like a smell of an bad architecture. Cache cache-worthy stuff in memcache or such and fetch only the data you need. Also: What should happen if the system runs out of memory while doing the cleanup? Anything sane doesn't sound good either. Yes running the GC is much faster except they are two completely different processes... in my example the dev is keeping references to data for possible future use later on however it's not possible to know when to release these references so php's GC can collect them if the user does not implement something quite juristic like ticks or frequent function calls throughout a code base. You can use ticks :) http://php.net/control-structures.declare#control-structures.declare.ticks Yes Ticks are something useable (like said above) however I have found ticks are clunky, frequently shunned, and you'd be ticking for no reason most of the time. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Should sessions override user sent headers?
Hi, so I stumbled upon this bug report: https://bugs.php.net/bug.php?id=64357 It's fairly easily fixable, but I don't know if it's even a bug... The problem here: sessions always send Expire header (except for private_no_expire), so if user (php user) sent Expire header before session_start() call, it will be replaced (see https://github.com/php/php-src/blob/master/ext/session/session.c#L1066 and ADD_HEADER macros for example). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposed changes to PHP language
Dear PHP Community,
I'd like to propose several changes to PHP core:
1. Allow re-throwing exceptions without losing original stack trace,
like in other technologies:
try {/*...*/} catch(Exception $e) { throw; }
2. Introduce base class for all PHP classes. E.g. Object. It would help
in type hinting and allow to add new common methods without any magic.
3. Parse body of PUT request in the same manner as it's done for POST
request. I guess it should be stored in $_POST array to maintain backward
compatibility. Otherwise $_REQUEST handling should be aware of new array
with PUT data.
4. Add handling of DateTime objects to SoapServer and SoapClient. It
will help in using this build-in datatype without typemap.
I tried to google for these proposals, but didn't find any previous
discussions.
--
Max Romanovsky
Re: [PHP-DEV] Proposed changes to PHP language
On 6 March 2013 12:48, Max Romanovsky max.romanov...@gmail.com wrote:
Dear PHP Community,
I'd like to propose several changes to PHP core:
1. Allow re-throwing exceptions without losing original stack trace,
like in other technologies:
try {/*...*/} catch(Exception $e) { throw; }
catch (Exception $e) { throw $e; }
This does what you want? (A quick test my end appears to keep the stack
trace in-tact at least)
2. Introduce base class for all PHP classes. E.g. Object. It would help
in type hinting and allow to add new common methods without any magic.
I like this idea.
3. Parse body of PUT request in the same manner as it's done for POST
request. I guess it should be stored in $_POST array to maintain
backward
compatibility. Otherwise $_REQUEST handling should be aware of new array
with PUT data.
I don't really like the idea of putting non-POST data in $_POST
It would still be nice to have a better way of handing PUT though.
Re: [PHP-DEV] Proposed changes to PHP language
On 06/03/13 13:48, Max Romanovsky wrote:
Dear PHP Community,
Hi,
I'd like to propose several changes to PHP core:
1. Allow re-throwing exceptions without losing original stack trace,
like in other technologies:
try {/*...*/} catch(Exception $e) { throw; }
throw $e will do the job.
2. Introduce base class for all PHP classes. E.g. Object. It would help
in type hinting and allow to add new common methods without any magic.
Introduce a type-hint “object” would be better I think. It would replace
is_object call.
3. Parse body of PUT request in the same manner as it's done for POST
request. I guess it should be stored in $_POST array to maintain backward
compatibility. Otherwise $_REQUEST handling should be aware of new array
with PUT data.
var_dump(file_get_contents('php://input'));
Why is it complicated? And place PUT request body in $_POST sounds a bad
idea :-).
4. Add handling of DateTime objects to SoapServer and SoapClient. It
will help in using this build-in datatype without typemap.
I tried to google for these proposals, but didn't find any previous
discussions.
Cheers :-).
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed changes to PHP language
2. Introduce base class for all PHP classes. E.g. Object. It would help in type hinting and allow to add new common methods without any magic. Introduce a type-hint “object” would be better I think. It would replace is_object call. I wonder how much BC breakage there would be introducing an Object class / type-hint though. Right now it's perfectly acceptable to define a class called Object (or object). An ugly solution could be to re-use stdClass as the base of all classes.
Re: [PHP-DEV] Proposed changes to PHP language
On 3/6/13 7:48 AM, Max Romanovsky wrote: 2. Introduce base class for all PHP classes. E.g. Object. It would help in type hinting and allow to add new common methods without any magic. Type-hinting for non-stdClass objects would be handy. Base class is like mutable Object.prototype in JS. I'm against it. 3. Parse body of PUT request in the same manner as it's done for POST There are arguments for/against here: https://bugs.php.net/bug.php?id=55815 compatibility. Otherwise $_REQUEST handling should be aware of new array with PUT data. For BC, PUT data should not be injected into existing vars. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed changes to PHP language
On 6 March 2013 15:50, Alexandre TAZ dos Santos Andrade
alexandre...@gmail.com wrote:
This item
2. Introduce base class for all PHP classes. E.g. Object. It would help
in type hinting and allow to add new common methods without any magic.
StdClass Already do that
?php
class A
{}
$obj = new A();
var_dump($obj instanceof StdClass);
Result:
bool(false)
3. Parse body of PUT request in the same manner as it's done for POST
+1
--
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype
[PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
On Wed, Feb 27, 2013 at 8:33 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've opened the voting the the foreach-keys RFC: https://wiki.php.net/rfc/foreach-non-scalar-keys#vote The discussion for this RFC can be found here: http://markmail.org/message/rzoacqaesxbd67lu The RFC was accepted unanimously, with 21 votes in favor. I'll merge the patch sometime soon. Thanks, Nikita
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: Em 2013-02-20 10:32, Stas Malyshev escreveu: This isn't really a good data since most of this code creates its own DateTime and thus there's very little relevancy to what we're talking about. If you look up the functions that actually accept DateTime: http://code.google.com/**codesearch#search/type=csq=** DateTime%5Cs%5C$%20lang:%**5Ephp$http://code.google.com/codesearch#search/type=csq=DateTime%5Cs%5C$%20lang:%5Ephp$ the picture would be quite different. I scanned through first 5 pages and couldn't find a function that actually calls modify() on DateTime object it receives. Well, the majority of the code here just calls -format() (which may very well be considered a point in your favor). But again most of the time an operation with side effects is called, there's no assignment. I also went through the first pages and saw one instance of an operation with side effects with assignment and three others without (setTime, setTimestamp and setTimeZone). It's very tedious to go through this because most that don't just call format just set a field with it. This is potentially dangerous, of course, depending on what's further done with the field. In any case, this seems like a pointless exercise. The solution is simple: separate the classes and provide a toDateTime() on DateTimeImmutable for interoperability purposes. One wouldn't need to go through Atom libraries code to know this is a solution that can't cause problems. This seems like a reasonable suggestion. If no such compromise can be reached, then I would suggest that the DateTimeImmutable addition be reverted altogether. Looking over the thread it seems that most people agree on the design flaws and those who don't are more or less indifferent about DateTimeImmutable either way (e.g. Stas). I'd prefer to have nothing over having something bad. Nikita
Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
Hi Nikita, few notes about the patch... - you may avoid estrndup() in zend_hash_current_key_zval_ex() for interned strings. - I didn't completely get why did you change the key operand type from IS_TMP_VAR to IS_VAR and how it affects performance As I understood now you need to allocate new zval on each loop iteration even for foreach over plain arrays. :( Thanks. Dmitry. On Wed, Mar 6, 2013 at 7:27 PM, Nikita Popov nikita@gmail.com wrote: On Wed, Feb 27, 2013 at 8:33 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! interned strings I've opened the voting the the foreach-keys RFC: https://wiki.php.net/rfc/foreach-non-scalar-keys#vote The discussion for this RFC can be found here: http://markmail.org/message/rzoacqaesxbd67lu The RFC was accepted unanimously, with 21 votes in favor. I'll merge the patch sometime soon. Thanks, Nikita
Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, few notes about the patch... - you may avoid estrndup() in zend_hash_current_key_zval_ex() for interned strings. Good idea, I'll do that. - I didn't completely get why did you change the key operand type from IS_TMP_VAR to IS_VAR and how it affects performance As I understood now you need to allocate new zval on each loop iteration even for foreach over plain arrays. :( Good point, I didn't consider the performance implication the type change would have. The intent behind that was to avoid copying the get_current_key zval into the temporary (and destroying it then), but I didn't consider how it affects normal arrays. This should be changed back to TMP_VAR. I wonder what would be a good way to avoid allocating a temporary zval for the key and freeing it again. Do you think it would be okay to pass EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value can be written directly into it without doing extra allocs/frees? Nikita
Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
On Wed, Mar 6, 2013 at 9:16 PM, Nikita Popov nikita@gmail.com wrote: On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, few notes about the patch... - you may avoid estrndup() in zend_hash_current_key_zval_ex() for interned strings. Good idea, I'll do that. - I didn't completely get why did you change the key operand type from IS_TMP_VAR to IS_VAR and how it affects performance As I understood now you need to allocate new zval on each loop iteration even for foreach over plain arrays. :( Good point, I didn't consider the performance implication the type change would have. The intent behind that was to avoid copying the get_current_key zval into the temporary (and destroying it then), but I didn't consider how it affects normal arrays. This should be changed back to TMP_VAR. It would be great. I can agree that new features may work slower, but really don't like when they slowdown existing and mach more usual cases. I wonder what would be a good way to avoid allocating a temporary zval for the key and freeing it again. Do you think it would be okay to pass EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value can be written directly into it without doing extra allocs/frees? I'm not sure it'll work. TMP_VARs don't initialize refcount, they can't be referenced or marked as a possible root of garbage. I took only a very quick look over the patch and didn't understand all the details, but probably it must be possible to copy iterator key into TMP_VAR and call copy_ctor(). Please, let me review the patch when it's ready (I won't be available on March 8 and weekend). Thanks. Dmitry.
[PHP-DEV] 回复： [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
Hi Nikita, I got some test failure with the patch, one test failure and some memory leaks. see: https://gist.github.com/reeze/5101596 -- reeze | reeze.cn 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 在 2013年3月7日星期四，上午1:28，Dmitry Stogov 写道： On Wed, Mar 6, 2013 at 9:16 PM, Nikita Popov nikita@gmail.com (mailto:nikita@gmail.com) wrote: On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov dmi...@zend.com (mailto:dmi...@zend.com) wrote: Hi Nikita, few notes about the patch... - you may avoid estrndup() in zend_hash_current_key_zval_ex() for interned strings. Good idea, I'll do that. - I didn't completely get why did you change the key operand type from IS_TMP_VAR to IS_VAR and how it affects performance As I understood now you need to allocate new zval on each loop iteration even for foreach over plain arrays. :( Good point, I didn't consider the performance implication the type change would have. The intent behind that was to avoid copying the get_current_key zval into the temporary (and destroying it then), but I didn't consider how it affects normal arrays. This should be changed back to TMP_VAR. It would be great. I can agree that new features may work slower, but really don't like when they slowdown existing and mach more usual cases. I wonder what would be a good way to avoid allocating a temporary zval for the key and freeing it again. Do you think it would be okay to pass EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value can be written directly into it without doing extra allocs/frees? I'm not sure it'll work. TMP_VARs don't initialize refcount, they can't be referenced or marked as a possible root of garbage. I took only a very quick look over the patch and didn't understand all the details, but probably it must be possible to copy iterator key into TMP_VAR and call copy_ctor(). Please, let me review the patch when it's ready (I won't be available on March 8 and weekend). Thanks. Dmitry.
[PHP-DEV] [RFC] unset(): return bool if the variable has existed
Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On 3/6/13 4:10 PM, Bob Weinand wrote: https://wiki.php.net/rfc/unset_bool What's the return value of unset($setValue, $undefined) ? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
false. It's like unset($setValue) unset($undefined). I've clarified this in the RFC; thank you. Bob Weinand Am 06.03.2013 um 22:24 schrieb Steve Clay st...@mrclay.org: On 3/6/13 4:10 PM, Bob Weinand wrote: https://wiki.php.net/rfc/unset_bool What's the return value of unset($setValue, $undefined) ? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Hello, On Wed, Mar 6, 2013 at 11:31 PM, Bob Weinand bobw...@hotmail.com wrote: false. It's like unset($setValue) unset($undefined). I've clarified this in the RFC; thank you. Bob Weinand Am 06.03.2013 um 22:24 schrieb Steve Clay st...@mrclay.org: On 3/6/13 4:10 PM, Bob Weinand wrote: https://wiki.php.net/rfc/unset_bool What's the return value of unset($setValue, $undefined) ? Steve Clay -- http://www.mrclay.org/ Would it make more sense to return an array with keys the name of the variables that were unset and the result for each of them? This way one could better handle 'false' being returned. I'm not sure if it's possible or not, I didn't had the time to check out the patch. Thanks Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Florin Would it make more sense to return an array with keys the name of the variables that were unset and the result for each of them? This way one could better handle 'false' being returned. I'm not sure if it's possible or not, I didn't had the time to check out the patch. If you need that much granularity, just call unset() individually for each one... Anthony
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php unset is not a function, but a language construct, and there is at least one similar construct which doesn't return anything (eg. not returning NULL, but syntax error when used in a return context): echo -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool I'm not a fan of this change, but if it's going to be discussed, the RFC should include baseline and RFC change benchmarks. Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php unset is not a function, but a language construct, and there is at least one similar construct which doesn't return anything (eg. not returning NULL, but syntax error when used in a return context): echo referring to This removes also an inconsistency: the function's return value is void, states the docs. It is until now the only function which has no return value. especially. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 4:40 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php unset is not a function, but a language construct, and there is at least one similar construct which doesn't return anything (eg. not returning NULL, but syntax error when used in a return context): echo referring to This removes also an inconsistency: the function's return value is void, states the docs. It is until now the only function which has no return value. especially. Agreed. The RFC needs to be updated as to not mislead readers. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Am 06.03.2013 um 22:47 schrieb Ferenc Kovacs tyr...@gmail.com: On Wed, Mar 6, 2013 at 10:41 PM, Bob Weinand bobw...@hotmail.com wrote: Am 06.03.2013 um 22:38 schrieb Ferenc Kovacs tyr...@gmail.com: On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php unset is not a function, but a language construct, and there is at least one similar construct which doesn't return anything (eg. not returning NULL, but syntax error when used in a return context): echo -- Ferenc Kovács @Tyr43l - http://tyrael.hu Echo doesn't behave as a function as it doesn't need parenthesis etc. (and has an equivalent which can be used as alternative: print) I'd consider unset as a function in form of a language construct. Bob Weinand I'm not sure that we should change our terminology based on whether or not a language construct requires the parenthesis or not. there are other differences in behavior, for example $foo = print;$foo(bar); won't work even thought that print(bar); look likes as a function call. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Ok; I think it's better not to argue about this... Bob Weinand
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 10:49 PM, Bob Weinand bobw...@hotmail.com wrote: Am 06.03.2013 um 22:47 schrieb Ferenc Kovacs tyr...@gmail.com: On Wed, Mar 6, 2013 at 10:41 PM, Bob Weinand bobw...@hotmail.com wrote: Am 06.03.2013 um 22:38 schrieb Ferenc Kovacs tyr...@gmail.com: On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com wrote: Hi! As this seem to require a RFC, here is it: https://wiki.php.net/rfc/unset_bool Please feedback, Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php unset is not a function, but a language construct, and there is at least one similar construct which doesn't return anything (eg. not returning NULL, but syntax error when used in a return context): echo -- Ferenc Kovács @Tyr43l - http://tyrael.hu Echo doesn't behave as a function as it doesn't need parenthesis etc. (and has an equivalent which can be used as alternative: print) I'd consider unset as a function in form of a language construct. Bob Weinand I'm not sure that we should change our terminology based on whether or not a language construct requires the parenthesis or not. there are other differences in behavior, for example $foo = print;$foo(bar); won't work even thought that print(bar); look likes as a function call. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Ok; I think it's better not to argue about this... Bob Weinand I'm glad that we sorted this out. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:39 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi!
As this seem to require a RFC, here is it:
https://wiki.php.net/rfc/unset_bool
I'm not a fan of this change, but if it's going to be discussed, the RFC
should include baseline and RFC change benchmarks.
Please feedback,
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't see here a real need for a benchmark as it is mostly only returning
SUCCESS or FAILURE instead of nothing. Nothing what would slow PHP down.
Any change to a language construct which requires additional processing adds
time. It may be in minute, but it's part of the discussion. Since this core
change you're requesting comments for introduces a usecase which many will
not find useful (probably most voting), it is your responsibility to convince
this category of people that the tradeoff won't affect them that much.
If you choose not to add benchmarking, I will guarantee a -1 from me.
Bob Weinand
I have tried the following:
time ./sapi/cli/php -r 'while($i++ 1e7) { $a = true; unset($a); }'
Unpatched: average of 5x executed:
real0m4.935s
user0m4.925s
sys 0m0.008s
Patched: average of 5x executed:
real0m4.945s
user0m4.938s
sys 0m0.005s
Yes, there is an increase of 0.15%. This is 1 nanosecond more than previous.
Is this exact enough? Or do you need more precision?
If yes, I'll put this into the RFC.
Bob Weinand
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:39 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi!
As this seem to require a RFC, here is it:
https://wiki.php.net/rfc/unset_bool
I'm not a fan of this change, but if it's going to be discussed, the RFC
should include baseline and RFC change benchmarks.
Please feedback,
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't see here a real need for a benchmark as it is mostly only
returning SUCCESS or FAILURE instead of nothing. Nothing what would slow
PHP down.
Any change to a language construct which requires additional processing
adds time. It may be in minute, but it's part of the discussion. Since
this core change you're requesting comments for introduces a usecase which
many will not find useful (probably most voting), it is your responsibility
to convince this category of people that the tradeoff won't affect them
that much.
If you choose not to add benchmarking, I will guarantee a -1 from me.
Bob Weinand
I have tried the following:
time ./sapi/cli/php -r 'while($i++ 1e7) { $a = true; unset($a); }'
Unpatched: average of 5x executed:
real 0m4.935s
user 0m4.925s
sys 0m0.008s
Patched: average of 5x executed:
real 0m4.945s
user 0m4.938s
sys 0m0.005s
Yes, there is an increase of 0.15%. This is 1 nanosecond more than
previous.
Is this exact enough? Or do you need more precision?
If yes, I'll put this into the RFC.
Thank you. Please do add to the RFC
Bob Weinand
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Am 6.3.2013 um 23:30 schrieb Will Fitch wfi...@meetme.com:
On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 06.03.2013 um 22:39 schrieb Will Fitch willfi...@php.net:
On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi!
As this seem to require a RFC, here is it:
https://wiki.php.net/rfc/unset_bool
I'm not a fan of this change, but if it's going to be discussed, the RFC
should include baseline and RFC change benchmarks.
Please feedback,
Bob Weinand
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't see here a real need for a benchmark as it is mostly only returning
SUCCESS or FAILURE instead of nothing. Nothing what would slow PHP down.
Any change to a language construct which requires additional processing adds
time. It may be in minute, but it's part of the discussion. Since this
core change you're requesting comments for introduces a usecase which many
will not find useful (probably most voting), it is your responsibility to
convince this category of people that the tradeoff won't affect them that
much.
If you choose not to add benchmarking, I will guarantee a -1 from me.
Bob Weinand
I have tried the following:
time ./sapi/cli/php -r 'while($i++ 1e7) { $a = true; unset($a); }'
Unpatched: average of 5x executed:
real 0m4.935s
user 0m4.925s
sys 0m0.008s
Patched: average of 5x executed:
real 0m4.945s
user 0m4.938s
sys 0m0.005s
Yes, there is an increase of 0.15%. This is 1 nanosecond more than previous.
Is this exact enough? Or do you need more precision?
If yes, I'll put this into the RFC.
Thank you. Please do add to the RFC
Bob Weinand
RFC updated.
Any other comments about this RFC?
Bob Weinand
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Hi! RFC updated. Any other comments about this RFC? Could you provide a use case for this - which practical value this has? It also still contains factually incorrect claim that unset() is a function and that there's some inconsistency in the fact that it does not return value. Also, it is not clear what false returned from unset() actually means - did it fail to unset the value (i.e., it is still set) or there was nothing to unset (i.e., it is still not set)? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
