I'll second that. I'm quite surprised that it was such a clean
addition to the parser. I owe you a few beers, Felipe.
-Joël
On Mon, Jun 7, 2010 at 9:16 PM, Jonathan Wage wrote:
> Thanks a bunch. This is a very nice improvement to PHP!
>
> - Jon
>
> On Mon, Jun 7, 2010 at 12:58 PM, Felipe Pena w
Thanks a bunch. This is a very nice improvement to PHP!
- Jon
On Mon, Jun 7, 2010 at 12:58 PM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page: http://wiki.php.net/rfc/functionarraydereferencing
>
> The patc
Thanks!
Very happy about this :]
-Tig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010/6/7 Stas Malyshev
> Hi!
>
>
> This is great. Did you check it on debug version though? I thought for
>> some reason you'd have to take care of freeing the value (which is
>> returned by function) after the expression is done, but maybe I missed
>> something. It's be also nice to see some mo
Hi!
This is great. Did you check it on debug version though? I thought for
some reason you'd have to take care of freeing the value (which is
returned by function) after the expression is done, but maybe I missed
something. It's be also nice to see some more assignment tests (also
maybe return-a
On Mon, Jun 7, 2010 at 9:22 PM, Pierre Joye wrote:
> hi Felipe,
>
> Great work! thanks :)
>
> Patches looks very good, builds on my tests system here.
>
> No objection for trunk :)
>
> Cheers,
>
> On Mon, Jun 7, 2010 at 6:58 PM, Felipe Pena wrote:
> > Hi all,
> > I just edited the RFC page [1] a
hi Felipe,
Great work! thanks :)
Patches looks very good, builds on my tests system here.
No objection for trunk :)
Cheers,
On Mon, Jun 7, 2010 at 6:58 PM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page:
Hello !
I have a problem with phar in PHP 5.3.2.
This is the script :
file_put_contents(__DIR__ . '/files/file.php', 'str_repeat('.', 100) . '\'; ?>');
$phar = new \Phar(__DIR__ . '/compressed.phar');
$phar->buildFromDirectory(__DIR__ . '/files', '/\.php$/');
$phar->setSignatureAlgorithm(\Pha
On 6/7/10 9:58 AM, Felipe Pena wrote:
> Hi all,
> I just edited the RFC page [1] about array dereferencing as now we have a
> patch for such.
>
> RFC page: http://wiki.php.net/rfc/functionarraydereferencing
>
> The patch is simple, it just required to change the grammar file. I also
> added some
Hi!
RFC page: http://wiki.php.net/rfc/functionarraydereferencing
The patch is simple, it just required to change the grammar file. I also
added some tests in the patch.
This is great. Did you check it on debug version though? I thought for
some reason you'd have to take care of freeing the
Hi all,
I just edited the RFC page [1] about array dereferencing as now we have a
patch for such.
RFC page: http://wiki.php.net/rfc/functionarraydereferencing
The patch is simple, it just required to change the grammar file. I also
added some tests in the patch.
Any objection? Thought? Improveme
Hi all,
2010/6/5 Felipe Pena
> Hi!
>
> 2010/6/4 Stas Malyshev
>
> Hi!
>>
>>
>> function call chaining (f()() if f() returns function), and array
>>> dereferencing (f()[0]) - (Stas)
>>>
>>
>> I did patch for f()() - it's referenced at
>> http://wiki.php.net/rfc/fcallfcall - but not for f()[] -
Heya,
stream_resolve_include_path [1] was introduced mostly to build framework
autoloaders. Good. It's great as it is. However it still forces the
framework to stash all its paths in the global include_path so that
they're picked up by that function.
Wouldn't it make sense to have an option, eith
Sorry for the ambiguity in my original message, and thanks to Tig for
PM-ing me about that.
To clarify, I support the syntax for:
> echo function(var)[0];
and I believe this syntax:
> $tmp = getimagesize('./path/to/image');
> echo $tmp[1];
to be awkward and inconvenient. Furthermore, it feels
14 matches
Mail list logo