> I noticed that multiple people who expressed support for the RFC on this
> thread have since cast "No" votes on the RFC. I'm confused. Does "No"
> correspond to supporting the idea in this case, or did something happen
> outside this thread that changed people's minds about it?
>
They probably
> ${'_'.!$_=getCallback()}();
>
Well now, that's an... interesting abuse of resolution order and type juggling.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Saturday, March 16, 2013, Rasmus Lerdorf wrote:
> On 03/15/2013 11:13 PM, Dmitry Stogov wrote:
> > Hi Rasmus,
> >
> > restart_count - makes sense
> >
> > last_restart_reason - is not very useful, I think it's better to add
> > separate countersfor each reason (memory overflow, hash overflow, wa
On 03/15/2013 11:13 PM, Dmitry Stogov wrote:
> Hi Rasmus,
>
> restart_count - makes sense
>
> last_restart_reason - is not very useful, I think it's better to add
> separate countersfor each reason (memory overflow, hash overflow, wasted
> memory).
>
> What do you think?
Sure, separate counter
Hi Rasmus,
restart_count - makes sense
last_restart_reason - is not very useful, I think it's better to add
separate counters for each reason (memory overflow, hash overflow, wasted
memory).
What do you think?
Dmitry.
On Saturday, March 16, 2013, Rasmus Lerdorf wrote:
> Hey Dmitry, I think it
Hey Dmitry, I think it would be helpful if we added two tuning status
entries. The first is a "restart_count" which lets you know how many
times the cache has restarted since server start. And the second, since
there are multiple triggers for a cache restart, would be a
"last_restart_reason" which
2013/3/15 Stas Malyshev
> Hi!
>
> > why not enable then this "getCallback()();"?
>
> There's an RFC for that: https://wiki.php.net/rfc/fcallfcall
> but it has some edge cases which I didn't have time to figure out yet.
>
In the long run I think it would be great :) Earlier I also realized, that
Hi!
> why not enable then this "getCallback()();"?
There's an RFC for that: https://wiki.php.net/rfc/fcallfcall
but it has some edge cases which I didn't have time to figure out yet.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP In
Am 15.3.2013 um 16:59 schrieb Anthony Ferrara :
> Bob,
>
> call_user_func is not call_user_func_array
>
> call_user_func($func) is the same as $func(). In any way.
>
> Not in any way. call_user_func accepts any expression for the function to
> call. `$func()` only accepts callables.
>
> Examp
Bob,
call_user_func is not call_user_func_array
>
> call_user_func($func) is the same as $func(). In any way.
>
Not in any way. call_user_func accepts any expression for the function to
call. `$func()` only accepts callables.
Example:
call_user_func(getCallback());
getCallback()(); // <-- synta
On 3/15/13 11:11 AM, Nikita Popov wrote:
I don't know why 'class::method' isn't supported, but I guess it's just a
legacy syntax that was superseded by the array notation
'class::method' was added significantly *later*, so I think it's fair for devs to assume
that it would be supported like ot
Am 15.3.2013 um 15:50 schrieb Ángel González :
> On 15/03/13 15:19, Steve Clay wrote:
>> I'm sure this question has been discussed before, so if anyone can
>> point to me to links or briefly recap I'd appreciate it.
>>
>> Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
>
I missed this. We'll soon have User::class. This may resolve to, e.g.,
'Foo\User'.
Right, and since the literal/string version of the class is as "1st
class citizen" as it could possibly get, it makes it easier for tools
like Studio/Storm/phpunit/etc to do better static analysis of class names
2013/3/15 Steve Clay
> My subject was misleading. I didn't mean to suggest call_user_func() be
> removed, just be made unnecessary by direct call syntax.
>
> This should make the inconsistency clearer: http://3v4l.org/L8Yvq
>
> On 3/15/13 10:21 AM, Sebastian Krebs wrote:
>
>> You don't need to us
On Fri, Mar 15, 2013 at 4:05 PM, Steve Clay wrote:
> My subject was misleading. I didn't mean to suggest call_user_func() be
> removed, just be made unnecessary by direct call syntax.
>
> This should make the inconsistency clearer: http://3v4l.org/L8Yvq
>
> On 3/15/13 10:21 AM, Sebastian Krebs wr
My subject was misleading. I didn't mean to suggest call_user_func() be removed, just be
made unnecessary by direct call syntax.
This should make the inconsistency clearer: http://3v4l.org/L8Yvq
On 3/15/13 10:21 AM, Sebastian Krebs wrote:
You don't need to use it, if you don't like it.
I do
On 15/03/13 15:19, Steve Clay wrote:
> I'm sure this question has been discussed before, so if anyone can
> point to me to links or briefly recap I'd appreciate it.
>
> Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
>
> I understand the problem of $obj->foo() where ->foo
On Mon, Feb 25, 2013 at 1:17 PM, Clint Priest wrote:
>
> On 2/21/2013 5:17 AM, David Muir wrote:
>>
>> On 21/02/2013, at 6:12 AM, Lazare Inepologlou wrote:
>>
>>>
>>> Long code is not always equivalent to readable code. A shorter syntax
>>> could
>>> improve readability in *some* cases.
>>>
>>> L
2013/3/15 Steve Clay
> I'm sure this question has been discussed before, so if anyone can point
> to me to links or briefly recap I'd appreciate it.
>
> Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
>
> I understand the problem of $obj->foo() where ->foo is a callable
I'm sure this question has been discussed before, so if anyone can point to me to links or
briefly recap I'd appreciate it.
Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq
I understand the problem of $obj->foo() where ->foo is a callable property. The workaround
could
The problem that this approach renames the commits an they are not the same
anymore (as in O+ repo).
Usage of subtree strategy is not perfect, but it's something that more or
less works.
Thanks. Dmitry.
On Fri, Mar 15, 2013 at 2:19 PM, Damien Tournoud wrote:
> On Fri, Mar 15, 2013 at 11:08 AM,
On Fri, Mar 15, 2013 at 11:08 AM, Dmitry Stogov wrote:
> This solution clones the history, but makes merging between PHP and O+ repo
> (it's going to be used for pecl build for old PHP versions) even more
> difficult.
>
> Thanks. Dmitry.
Not sure. Merging between the two repositories using the su
This solution clones the history, but makes merging between PHP and O+ repo
(it's going to be used for pecl build for old PHP versions) even more
difficult.
Thanks. Dmitry.
On Fri, Mar 15, 2013 at 1:53 PM, Damien Tournoud wrote:
> On Fri, Mar 15, 2013 at 10:24 AM, Dmitry Stogov wrote:
> > I me
On Fri, Mar 15, 2013 at 10:24 AM, Dmitry Stogov wrote:
> I mean not "git subtree merge" but "git read-dir --prefix ...".
> Actually it imports all the history form O+ repo, but it's recorded with
> original patches (e.g. ZendAccelerator.h instead of moved
> ext/ZendOptimizerPlus/ZendAccelerator.h)
Yeah, I'm working in this direction.
Agree, it's better to do it before the merging.
Thanks. Dmitry.
On Fri, Mar 15, 2013 at 1:33 PM, Pierre Joye wrote:
> On Fri, Mar 15, 2013 at 10:24 AM, Dmitry Stogov wrote:
> > I mean not "git subtree merge" but "git read-dir --prefix ...".
> > Actually it
On Fri, Mar 15, 2013 at 10:24 AM, Dmitry Stogov wrote:
> I mean not "git subtree merge" but "git read-dir --prefix ...".
> Actually it imports all the history form O+ repo, but it's recorded with
> original patches (e.g. ZendAccelerator.h instead of moved
> ext/ZendOptimizerPlus/ZendAccelerator.h)
I mean not "git subtree merge" but "git read-dir --prefix ...".
Actually it imports all the history form O+ repo, but it's recorded with
original patches (e.g. ZendAccelerator.h instead of moved
ext/ZendOptimizerPlus/ZendAccelerator.h), so you can see it running "git
log", but not "git log ext/Zend
2013/3/15 Dmitry Stogov :
> Hi,
>
> For now, I'm trying subtree merging (See http://git-scm.com/book/ch6-7.htmland
> https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
> )
>
> You may see the result at https://github.com/dstogov/php-src/tree/PHP-5.5/
>
> This is not an
Kris Craig wrote:
I noticed that multiple people who expressed support for the RFC on this
thread have since cast "No" votes on the RFC. I'm confused. Does "No"
correspond to supporting the idea in this case, or did something happen
outside this thread that changed people's minds about it?
Ho
29 matches
Mail list logo
