Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

[Stas Malyshev]

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

Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

[Bob Weinand]

Am 6.3.2013 um 23:30 schrieb Will Fitch :
> On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand  wrote:
> Am 6.3.2013 um 22:50 schrieb Will Fitch :
>> On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand  wrote:
>> Am 06.03.2013 um 22:39 schrieb "Will Fitch" :
>>> On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand  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

[Will Fitch]

On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand  wrote:

> Am 6.3.2013 um 22:50 schrieb Will Fitch :
>
> On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand  wrote:
>
>> Am 06.03.2013 um 22:39 schrieb "Will Fitch" :
>>
>> On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand  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

[Bob Weinand]

Am 6.3.2013 um 22:50 schrieb Will Fitch :

> On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand  wrote:
> Am 06.03.2013 um 22:39 schrieb "Will Fitch" :
> 
>> On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand  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

[Ferenc Kovacs]

On Wed, Mar 6, 2013 at 10:49 PM, Bob Weinand  wrote:

> Am 06.03.2013 um 22:47 schrieb "Ferenc Kovacs" :
>
>
>
>
> On Wed, Mar 6, 2013 at 10:41 PM, Bob Weinand  wrote:
>
>> Am 06.03.2013 um 22:38 schrieb "Ferenc Kovacs" :
>>
>>
>> On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand  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

[Bob Weinand]

Am 06.03.2013 um 22:47 schrieb "Ferenc Kovacs" :

> 
> 
> 
> On Wed, Mar 6, 2013 at 10:41 PM, Bob Weinand  wrote:
> Am 06.03.2013 um 22:38 schrieb "Ferenc Kovacs" :
> 
>> 
>> On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand  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

[Will Fitch]

On Wed, Mar 6, 2013 at 4:40 PM, Ferenc Kovacs  wrote:

> On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs  wrote:
>
> >
> >
> >
> > On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand 
> 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

[Ferenc Kovacs]

On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs  wrote:

>
>
>
> On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand  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

[Will Fitch]

On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand  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

[Ferenc Kovacs]

On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand  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

[Anthony Ferrara]

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

[Florin Razvan Patan]

Hello,

On Wed, Mar 6, 2013 at 11:31 PM, Bob Weinand  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" :
>
>> 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

[Bob Weinand]

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" :

> 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

[Steve Clay]

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-DEV] [RFC] unset(): return bool if the variable has existed

[Bob Weinand]

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

[PHP-DEV] 回复： [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

[Reeze Xia]

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  (mailto:nikita@gmail.com)> wrote:
>  
> > On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov  > (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.  

Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

[Dmitry Stogov]

On Wed, Mar 6, 2013 at 9:16 PM, Nikita Popov  wrote:

> On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov  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.

Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

[Nikita Popov]

On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov  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

[Dmitry Stogov]

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  wrote:

> On Wed, Feb 27, 2013 at 8:33 PM, Nikita Popov 
> 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] Questions regarding DateTimeImmutable

[Nikita Popov]

On Wed, Feb 20, 2013 at 11:21 AM, Gustavo Lopes wrote:

> 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=cs&q=**
>> 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

[PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach

[Nikita Popov]

On Wed, Feb 27, 2013 at 8:33 PM, Nikita Popov  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] Proposed changes to PHP language

[Peter Lind]

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
>
>

>  3. Parse body of PUT request in the same manner as it's done for POST

+1

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Proposed changes to PHP language

[Steve Clay]

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

[Leigh]

>
>
>  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

[Ivan Enderlin @ Hoa]

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

[Leigh]

On 6 March 2013 12:48, Max Romanovsky  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.

[PHP-DEV] Proposed changes to PHP language

[Max Romanovsky]

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

[PHP-DEV] Should sessions override user sent headers?

[Nikita Nefedov]

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

Re: [PHP-DEV] Memory warning hook

[Julien Pauli]

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,  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
>
>