Hi!
> - in some cases destruction of temporary result may cause destruction of
> final result
>
> ((object)(array("a"=>"b")))->a = "c"; // temporary object may be destroyed
> before assignment
I remember now this was somewhat of a problem - when the temp is
destroyed? I.e. I guess we could stick
Ok I get that, thankyou for the explanation.
static::class is not an option. I'm trying to resolve class names defined in
docblocks, since phpdoc2 allows for entering type hints (classes) as
namespace/use relative. And I can tell there is no current way of resolving
class names in strings, to F
Hi Nikita,
I like the idea.
But note, that it may cause some unexpected behaviour and bugs.
I didn't test the patch I just guess it on my previous experience
introducing similar features.
- usage expression in write context (e.g. passing constant by reference)
function foo(&$foo) {}
foo("abc"[0]
On 02/25/2013 04:33 PM, Sara Golemon wrote:
When it comes to changing syntax, there is no such thing as too small
of an RFC IMO. Runtime changes can occasionally be hand-waved, but
syntax changes are serious business.
Seeing this quoted makes me realize I expressed myself poorly. What I
me
>>> When it comes to changing syntax, there is no such thing as too small
>>> of an RFC IMO. Runtime changes can occasionally be hand-waved, but
>>> syntax changes are serious business.
>
Seeing this quoted makes me realize I expressed myself poorly. What I
meant to convey was:
When it comes to
Am 26.02.2013 um 00:08 schrieb "Stas Malyshev" :
> Hi!
>
>> Don't consider it as a syntax change, only as a bugfix. It must have been a
>> bug, that this degree of conformity was not yet reached. :-P
>
> If it changes syntax, it's by definition a syntax change. It does not
> matter if you think
2013/2/25 Nikita Popov
> Hi internals!
>
> PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
> Foo)->bar and (new Foo)['bar'].
>
> I'd like to extend this support to any expression instead of just new.
>
> Why should be do this? Because it's just an arbitrary restriction. R
Hi!
> Don't consider it as a syntax change, only as a bugfix. It must have been a
> bug, that this degree of conformity was not yet reached. :-P
If it changes syntax, it's by definition a syntax change. It does not
matter if you think it should be changed and if you think it's a bug, it
still sho
On Mon, 2013-02-25 at 23:20 +0100, Bob Weinand wrote:
> Don't consider it as a syntax change, only as a bugfix. It must have been a
> bug, that this degree of conformity was not yet reached. :-P
>
> It's only stupid to vote about such microscopic changes as long as there are
> no real arguments ag
Hi Nikita,
Am 25.02.2013 um 23:20 schrieb Bob Weinand :
[...]
>> When it comes to changing syntax, there is no such thing as too small
>> of an RFC IMO. Runtime changes can occasionally be hand-waved, but
>> syntax changes are serious business.
I very much like it, it’s a good change. But can we
Am 25.2.2013 um 23:07 schrieb Sara Golemon :
>> (For me, it's changes like Sara's trailing comma proposal that are too
>> small to have needed an RFC)
>>
> When it comes to changing syntax, there is no such thing as too small
> of an RFC IMO. Runtime changes can occasionally be hand-waved, but
>
> (For me, it's changes like Sara's trailing comma proposal that are too
> small to have needed an RFC)
>
When it comes to changing syntax, there is no such thing as too small
of an RFC IMO. Runtime changes can occasionally be hand-waved, but
syntax changes are serious business.
-Sara
--
PHP In
PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
Foo)->bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
I like it, we discussed this 2 years ago, could you address my original
use case? Would it work:
$value = ($obj
Am 25.2.2013 um 22:01 schrieb Johannes Schlüter :
> On Mon, 2013-02-25 at 20:36 +0100, Bob Weinand wrote:
>>
>> I can increase the default limit to 1000, but if it is too high it has
>> exactly no sense.
>
> Which is exactly the issue i mentioned about being a "good default"
>
>> We don't discu
On Mon, 2013-02-25 at 20:36 +0100, Bob Weinand wrote:
>
> I can increase the default limit to 1000, but if it is too high it has
> exactly no sense.
Which is exactly the issue i mentioned about being a "good default"
> We don't discuss about xDebug, but about integrating it into the
> core?
We
Forgotten to cc to internals list:
Am 25.2.2013 um 19:50 schrieb Stas Malyshev :
> Hi!
>
>> You may use recursive functions (which are limited by the memory_limit),
>> but if you use recursive magics, it's a design error. This is not the purpose
>> of magics (, call_user_func(_array)?) and simp
Hi!
> You may use recursive functions (which are limited by the memory_limit),
> but if you use recursive magics, it's a design error. This is not the purpose
> of magics (, call_user_func(_array)?) and simply an abuse of the language.
I think you are confusing magic functions with internal funct
hi,
On Mon, Feb 25, 2013 at 7:40 PM, Dennis Clarke wrote:
>> However one should wait for the next release, there is 2 BC breaks in
>> this version, if you rely on the multi interface and non default
>> backed for DNS resolutions.
>
> * sigh *
>
> There always seems to be another release around th
hi,
On Mon, Feb 25, 2013 at 7:12 PM, Christopher Jones
wrote:
> I think a brief RFC would be good to clarify and give some more examples of
> what "any expression" is. Seeing more examples would help people
> evaluate the impact and see the use cases. It would also help the doc
> process.
>
> (
> hi,
>
> On Mon, Feb 25, 2013 at 7:58 AM, Dennis Clarke
> wrote:
> >
> > configure in php 5.4.12 seems to have some difficulty with libcurl
> 7.29.0 :
> >
> > $ ./configure --with-apxs2=/usr/local/bin/apxs
> --with-mysql=/opt/mysql/mysql \
>
> Also we had no issue to build against 7.29.0 on
hi,
On Mon, Feb 25, 2013 at 7:58 AM, Dennis Clarke wrote:
>
> configure in php 5.4.12 seems to have some difficulty with libcurl 7.29.0 :
>
> $ ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \
Also we had no issue to build against 7.29.0 on windows and linux.
However
Am 25.2.2013 um 19:10 schrieb Stas Malyshev :
> Hi!
>
>> Yes, but you can do an approximation. And in 99.999% of the cases 100
>> will be enough. I can hardly imagine a case where you need to do over
>> 100 implicit function calls. They should fit in every normal stack size of
>> servers today.
>
Am 25.2.2013 um 19:08 schrieb Stas Malyshev :
> Hi!
>
>>
>> p.s.: There is no reason why not to fix this in this way, I think,
>
> There actually is. First, any option modifying engine behavior creates a
> compatibility problem, since now the code that needs to work with it has
> to check and b
On 02/25/2013 08:14 AM, Nikita Popov wrote:
Hi internals!
PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
Foo)->bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
Why should be do this? Because it's just an arbitrary rest
Hi!
> Yes, but you can do an approximation. And in 99.999% of the cases 100
> will be enough. I can hardly imagine a case where you need to do over
> 100 implicit function calls. They should fit in every normal stack size of
> servers today.
Depth-first search in a modest-size data structure woul
Hi!
>
> p.s.: There is no reason why not to fix this in this way, I think,
There actually is. First, any option modifying engine behavior creates a
compatibility problem, since now the code that needs to work with it has
to check and be tested for yet another variable. Second, why does it
concen
Yeah, like this as well, and +1 for consistency.
> PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
> Foo)->bar and (new Foo)['bar'].
>
> I'd like to extend this support to any expression instead of just new.
>
A winner is you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Feb 25, 2013 5:14 PM, "Nikita Popov" wrote:
>
> Thoughts?
I like the idea. I can't see nor imagine any BC breaks that could be
introduce by this change.
Cheers,
Am 25.2.2013 um 17:45 schrieb Johannes Schlüter :
> On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote:
>> p.s.: There is no reason why not to fix this in this way, I think, as
>> you can test at how may iterations the stack will overflow and set the
>> limit near to this maximum. Which is exact
> On Mon, 2013-02-25 at 10:49 -0500, Dennis Clarke wrote:
> >
> > /* The size of `long', as computed by sizeof. */
> > #define CURL_SIZEOF_LONG 8
> >
> This is correct with -m64. Now in your config log there is this compiler
> call (quoting your first mail from this thread)
>
> | configure:2867
On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote:
> p.s.: There is no reason why not to fix this in this way, I think, as
> you can test at how may iterations the stack will overflow and set the
> limit near to this maximum. Which is exactly what we have already
> today, only without possible c
It makes sense to me. +1 for making the syntax more consistent and natural.
- Jon
On Mon, Feb 25, 2013 at 10:14 AM, Nikita Popov wrote:
> Hi internals!
>
> PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
> Foo)->bar and (new Foo)['bar'].
>
> I'd like to extend this sup
> So the -m64 is lost. Looking at extg/curl/config.m4, again I see
>
> save_CFLAGS="$CFLAGS"
> CFLAGS="`$CURL_CONFIG --cflags`"
>
> So running `curl-config --cflags` apparently doesn't contain the -m64
> flag on your setup. In my opinion curl-config should return this, so
> there is a c
Hi internals!
PHP 5.4 added support for expressions of the kind (new Foo)->bar(), (new
Foo)->bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
Why should be do this? Because it's just an arbitrary restriction. Removing
it would for example allow clo
On Mon, 2013-02-25 at 10:49 -0500, Dennis Clarke wrote:
>
> /* The size of `long', as computed by sizeof. */
> #define CURL_SIZEOF_LONG 8
>
This is correct with -m64. Now in your config log there is this compiler
call (quoting your first mail from this thread)
| configure:28678: checking for ope
- Original Message -
From: Johannes Schlüter
Date: Monday, February 25, 2013 9:17 am
Subject: Re: [PHP-DEV] PHP 5.4.12 and libcurl 7.29.0 configure problem
To: Dennis Clarke
Cc: internals@lists.php.net, christopher.jo...@oracle.com
> On Mon, 2013-02-25 at 09:08 -0500, Dennis Clarke wr
Hi!
https://github.com/php/php-src/pull/290
How should I name the ini parameter?
max_magic_calls (magic ?=? everything which is not a direct function call)
max_implicit_calls
max_implicit_function_calls
Or what do you think is the most self documenting name?
Bob
p.s.: There is no reason why n
On Tue, Feb 19, 2013 at 3:12 PM, Etienne Kneuss wrote:
>
>
>
> On Tue, Feb 19, 2013 at 2:55 PM, Derick Rethans wrote:
>
>> Gah, no top posting!
>>
>> On Tue, 19 Feb 2013, Etienne Kneuss wrote:
>>
>> > On Tue, Feb 19, 2013 at 2:25 PM, Derick Rethans wrote:
>> >
>> > > On Tue, 19 Feb 2013, Nikita
On 02/25/2013 02:43 PM, Nils Andre wrote:
> strings. Not going too much into details here, many programmes always have
> to look up the function definition because very similar functions have
> their parameters in different orders or simply don't act in a predictive,
> well-structured manner. This
Hello,
See the reply inline:
On Mon, Feb 25, 2013 at 3:43 PM, Nils Andre wrote:
> Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
> the list at first. There has been ongoing discussion about new APIs and so
> fort, so this is a suggestion for language cleanup by Autob
On Mon, 2013-02-25 at 09:08 -0500, Dennis Clarke wrote:
> > So my guess would be that there is some mix between 32 and 64 bit
> mode,
> > try compiling with setting CFLAGS="-m64" (or CFLAGS="-m32") for
> > configure.
>
> Everything here is -m64 and -xtarget=ultraT2 so not sure where else to
> look
> Hi,
>
> On Mon, 2013-02-25 at 01:58 -0500, Dennis Clarke wrote:
> >
> > "/usr/local/include/curl/curlrules.h", line 143: zero or negative
> > subscript
> > "/usr/local/include/curl/curlrules.h", line 153: zero or negative
> > subscript
> > "conftest.c", line 249: warning: implicit function dec
It's a good idea, IMHO. This particular paragraph should probably be removed:
"It would also allow many brilliant constructs like the following
if ($b->startsWith("This")) { ... }
in contrast to
if (substr($b,0,4) == "This") { ... }
Notice that the latter is error-prone, because if t
2013/2/25 Nils Andre
> Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
> the list at first. There has been ongoing discussion about new APIs and so
> fort, so this is a suggestion for language cleanup by Autoboxing. I'd
> really appreciate comments.
>
> == Introduction
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.
== Introduction ==
This RFC tries to approach the
On 03/02/13 15:27, Hans-Juergen Petrich wrote:
In this example (using php-5.4.11 on Linux) the memory will grow
non-stop:
for ( $fp = fopen('/dev/urandom', 'rb'); true;) {
eval ('$ano_fnc = function() {$x = "'.bin2hex(fread($fp,
mt_rand(1, 1))).'";};');
echo "Mem usage: ".memory_g
Hi,
On Mon, 2013-02-25 at 01:58 -0500, Dennis Clarke wrote:
>
> "/usr/local/include/curl/curlrules.h", line 143: zero or negative
> subscript
> "/usr/local/include/curl/curlrules.h", line 153: zero or negative
> subscript
> "conftest.c", line 249: warning: implicit function declaration:
> strncas
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.
Long:
$users->OrderBy( function( $x ){ return $x->Surname; } );
Short:
$users->Order
hi!
While reading both PRs and features requests in bugs.php.net, I would
like to strongly suggest to make any new proposal (new features, PRs,
etc.), no matter how small, targeting 5.6 or later.
5.5 will go in beta soon and we have already enough new things to
debug and test. Adding more stuff w
On Mon, 25 Feb 2013 14:00:04 +0400, Jens Riisom Schultz
wrote:
Hi everybody,
I have read up on this, and done some testing.
First up, my findings with PHP5.5 alpha5:
I'm trying to late resolve a class name contained in a variable to the
FQCN. I understand that this is hard (maybe even
2013/2/25 Jens Riisom Schultz
> Hi everybody,
>
> I have read up on this, and done some testing.
>
> First up, my findings with PHP5.5 alpha5:
>
> namespace spacy;
>
> class classy {
> public static function fqcn() {
> /* This works but is not useful enough: */
>
You can use the "static" late static binding keyword for this, it works,
see:
http://3v4l.org/l9Z5Y
On Mon, Feb 25, 2013 at 11:00 AM, Jens Riisom Schultz wrote:
> Hi everybody,
>
> I have read up on this, and done some testing.
>
> First up, my findings with PHP5.5 alpha5:
>
> namespace spacy;
Hi everybody,
I have read up on this, and done some testing.
First up, my findings with PHP5.5 alpha5:
I'm trying to late resolve a class name contained in a variable to the FQCN. I
understand that this is hard (maybe even impossible) with the current
implementation, because class name resol
54 matches
Mail list logo
