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
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;
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: */
>
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
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 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,
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 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 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
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
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
> 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
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
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 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
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
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
- 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
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
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
> 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
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
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
> 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
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 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,
> 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.
Yeah, like this as well, and +1 for consistency.
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
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
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
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
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.
>
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
> 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: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: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!
> 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
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
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
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
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
> (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
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
>
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
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!
> 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
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
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
>>> 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
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
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]
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!
> - 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
54 matches
Mail list logo
