Re: [PHP-DEV] Re: Deprecate and remove calls from incompatible context
Todd Ruth wrote: Could there be a compromise that would allow us evildoers to continue in our evil ways without identifying and changing every use? Perhaps implements allowStaticCallsFromIncompatibleContexts or somesuch? I can imagine replacing every class ... with class ... implements ..., but identifying and changing every place we use an incompatible context will be very, very unpleasant. We can figure out the places that are hit most frequently using the logs, but that isn't necessarily a complete list. It's all this 'implements' and the like which is complicating things along with 'the proper way of doing things' The exercise that I am STILL working through is one where an objects function used to be used statically as well as via $this ... if $this existed use it otherwise generate a static result. As far as I am concerned still there was nothing wrong, but I've gone through the exercise and written a HECK of a lot more code switching a single function into three functions! A static call, a $this call and often a further static function that has the shared code. I forget now why the static call could not be used directly ... OH matched parameters across all classes ... the base static has a subset of the class ones. The main point here is that there was nothing functionally wrong with the PHP5.2 code, it had been doing it's job perfectly, leave E_STRICT off and the code continues to work! I don't like this comparison with E_DEPRECATED, that is a different concept in my mind ... E_STRICT is purely style police imposing other peoples style choices, so the current debate IS appropriate, and it's nice to hear a few more voices against some of this. I can see that the resulting code changes improve the code, but I know I am still missing a lot of the 'style changes' that I SHOULD be using simply because of only hitting the E_STRICT warnings. It's a decent 'style' scanner that is needed rather than these odd warnings in the core code :( To some extent phpdocumenter helps here as the generated documents do flag up some of what as been missed but certainly not all. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 30/01/13 00:54, Rasmus Lerdorf wrote:
On 01/29/2013 04:47 PM, Stas Malyshev wrote:
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too.
But I don't think getting rid of it is that hard. It obviously can't be
done in the opcode cache because by the time the compiler hands us the
op_array we have already lost the FETCH_CLASS opcode which we may or may
not need. We need to look at whether that MAKE_NOP() call in the
compiler is actually a worthwhile optimization in a future where most
people will be running an opcode cache by default.
This is one of the prime examples of making the compiler more opcode
cache friendly. Yes, it may be at the slight expense of non-opcode cache
performance, but with a bundled opcode cache implementation that should
be less of a worry.
+1. This one makes no sense to me as it simply hoists the
zend_do_inheritance() from runtime binding to compile-time, and this
binding has to be backed out by any opcode cache to work properly. It
might save a few microseconds per class declaration in non-cached
performance, but add factors more to cached performance. Why do this?
[PHP-DEV] Proposal: php://memory/id ( ://temp/id)
Hi internals,
The php://memory, and its respectful sibling php://temp, appear very
useful when we need to compute streams on-the-fly. They offer a lot of
services, like avoiding HDD accesses, increasing speed... and through a
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+').
However, we always work on the same bucket/space of data (per
runtime), which prevent us to use two different streams at a time. My
proposal is to allow access to many buckets/spaces to php://memory and
its sibling.
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
We append /id to the existing syntax. Thus, it would be possible to
work on php://memory/foo and php://memory/bar without collisions between
them. They would represent two distinct buckets/spaces.
The implementation does not seem to require a ton of work, and the use
cases are numerous regarding the services offered by these wrappers.
Thoughts?
Best regards.
--
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/
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
Hi Ivan,
I've never actually worked with them, but it seems nice. However, we should
make redirect php://memory and php://temp to php://memory/default and
php://temp/default respectively to avoid break stuff imho.
Cheers,
r1pp3rj4ck
On Thu, Jan 31, 2013 at 10:37 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi internals,
The php://memory, and its respectful sibling php://temp, appear very
useful when we need to compute streams on-the-fly. They offer a lot of
services, like avoiding HDD accesses, increasing speed... and through a
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+'). However,
we always work on the same bucket/space of data (per runtime), which
prevent us to use two different streams at a time. My proposal is to allow
access to many buckets/spaces to php://memory and its sibling.
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:**size
We append /id to the existing syntax. Thus, it would be possible to work
on php://memory/foo and php://memory/bar without collisions between them.
They would represent two distinct buckets/spaces.
The implementation does not seem to require a ton of work, and the use
cases are numerous regarding the services offered by these wrappers.
Thoughts?
Best regards.
--
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/
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 11:00, Attila Bukor wrote: Hi Ivan, Hi Attila, I've never actually worked with them, but it seems nice. However, we should make redirect php://memory and php://temp to php://memory/default and php://temp/default respectively to avoid break stuff imho. Obviously yes! Sorry, I miss to precise this point. Thank you for the comment. Best regards. -- 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
[PHP-DEV] Re: [lists.php] [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
Hi Ivan, php://memory/id php://temp/id/maxmemory:size It's not that hard to write such an function in php. (http://www.php.net/manual/en/function.stream-wrapper-register.php). I even once wrote an handler like string://data-right-here which allows to read (only) the data-right-here as a file. (I used it for a function which required a file and does not support strings directly, and instead of php://memory all data is freed when no longer used) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Best regards
Chris Wright
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you need
to define an id for it?
Bu whats about
file_put_contents('php://memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect, that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Regards,
Sebastian
Best regards
Chris Wright
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Re: [lists.php] [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 11:12, ALeX wrote: Hi Ivan, php://memory/id php://temp/id/maxmemory:size It's not that hard to write such an function in php. (http://www.php.net/manual/en/function.stream-wrapper-register.php). Did I say it was hard? This is quite obvious to write such a wrapper, but PHP has php://memory. My proposal will save future work to users (and offer better performance because we stay in the PHP land). I even once wrote an handler like string://data-right-here which allows to read (only) the data-right-here as a file. (I used it for a function which required a file and does not support strings directly, and instead of php://memory all data is freed when no longer used) Yes. I also have Hoa\Stringbuffer or some stuff like that. But, again, it will save future work to users. Best regards. -- 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] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 12:00, Sebastian Krebs wrote:
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you need
to define an id for it?
Bu whats about
file_put_contents('php://memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect, that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Yup, I also expect the engine to clean memory when closing php://memory
or php://temp, but this is another proposal I think, no?
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Is this question for me or Chris? If it is for me, I don't want multiple
accesses to the same “bucket”/space, I want multiple “buckets”/spaces.
Best regards.
--
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] Proposal: php://memory/id ( ://temp/id)
2013/1/31 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
On 31/01/13 12:00, Sebastian Krebs wrote:
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:**size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://**memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you need
to define an id for it?
Bu whats about
file_put_contents('php://**memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect,
that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Yup, I also expect the engine to clean memory when closing php://memory or
php://temp, but this is another proposal I think, no?
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Is this question for me or Chris?
A question for everone :)
If it is for me, I don't want multiple accesses to the same
“bucket”/space, I want multiple “buckets”/spaces.
So now I am confused: As far as I can see you can open as many memory- or
temp-streams as you like.
Best regards.
--
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
--
github.com/KingCrunch
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
The php://memory, and its respectful sibling php://temp, appear very
useful when we need to compute streams on-the-fly. They offer a lot of
services, like avoiding HDD accesses, increasing speed... and through a
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+').
However, we always work on the same bucket/space of data (per
runtime), which prevent us to use two different streams at a time. My
proposal is to allow access to many buckets/spaces to php://memory and
its sibling.
I'm not sure what you mean here. Each time you open a php://memory stream,
you're working on a new bucket, right?
$ cat a.php php a.php
?php
$f1 = fopen(php://memory, r+);
$f2 = fopen(php://memory, r+);
fwrite($f1, foobar);
array_map(function($f) {
rewind($f);
var_dump(stream_get_contents($f));
}, [$f1, $f2]);
string(6) foobar
string(0)
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 12:00, Sebastian Krebs wrote:
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you
need to define an id for it?
Bu whats about
file_put_contents('php://memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect,
that the engine will cleanup the memory (at least sooner or later),
but then I open it again.
Yup, I also expect the engine to clean memory when closing php://memory or
php://temp, but this
is another proposal I think, no?
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Is this question for me or Chris? If it is for me, I don't want multiple
accesses to the same bucket/space, I want multiple buckets/spaces.
My thinking was for stuff like ZipArchive, which does not accept streams, only
paths. As it is
there is no way to use ZipArchive entirely in memory, you have to write it to
disk (it also currently
cannot cope with URLs so this alone would not fix it, but that's another
story). I admit the use case
is narrow, but I do have a specific case where I need to post-process the
resulting data before
outputting/writing to the final file, this functionality would be a step
towards working around this.
I'm sure there are other examples of this as well.
As ALeX pointed out, there are other ways to work in this manner using custom
stream wrappers, and if
it would be too difficult/wouldn't make sense to the engine to do this, then so
be it :)
Best Regards
Chris Wright
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
The fact that this use of PHP is documented in the manual as a feature www.php.net/manual/en/**language.oop5.basic.phphttp://www.php.net/manual/en/language.oop5.basic.php And mentions that it will elicit a E_STRICT error - does not indicate that it would be DEPRECATED, I'm assuming that has been documented for years, and only recently (a year or two) has the E_STRICT comment been added. There is also no real Justification for the E_STRICT message = see suggestion at end.. I stand corrected, I said that (AFAIR) is an undocumented feature, but as you pointed out, it is documented since (at least) 2004: http://svn.php.net/viewvc/phpdoc/en/trunk/language/oop5/basic.xml?view=markuppathrev=166424 (there is a typo here, so it is called a psudo variable) And an example was added in 2005: http://svn.php.net/viewvc?view=revisionrevision=178495 by sean (funny commit comment: 'document seemingly-odd $this behaviour'). The E_STRICTs were added to the examples in 2009: http://svn.php.net/viewvc?view=revisionrevision=288217 This doesn't really change my opinion, but it means that there could be more people using this feature than I/we assumed. Given the fact that this already spits E_STRICT(and E_STRICT is part of E_ALL since 5.4) and both E_STRICT and E_DEPRECATED is disable in our php.ini-production, I would say that changing this from E_STRICT to E_DEPRECATED has no direct impact to the userland. But we can use this change to sample the people using this feature and based on the feedback we can decide whether we want to keep this or remove it for the next version. So my opinion is that we should stick to the vote and deprecate this feature but update the RFC and remove the part removing it in the next version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 12:18, Gustavo Lopes wrote:
On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
The php://memory, and its respectful sibling php://temp, appear very
useful when we need to compute streams on-the-fly. They offer a lot of
services, like avoiding HDD accesses, increasing speed... and through a
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+').
However, we always work on the same bucket/space of data (per
runtime), which prevent us to use two different streams at a time. My
proposal is to allow access to many buckets/spaces to php://memory and
its sibling.
I'm not sure what you mean here. Each time you open a php://memory
stream, you're working on a new bucket, right?
Yes exact. My bad. But my proposal still persist. Identifying
php://memory buckets would be nice to retrieve them. For example:
$f1 = fopen('php://memory/foo', 'r+');
fwrite($f1, 'foobar');
unset($f1);
$f1prime = fopen('php://memory/foo', 'r+');
rewind($f1);
var_dump(stream_get_contents($f1)); // string(6) foobar
Is it interesting? In this way, we have a similar behavior than
php://fd/i, file://, http:// etc.
Best regards.
--
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] Proposal: php://memory/id ( ://temp/id)
On Thu, 31 Jan 2013 14:55:26 +0100, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
I'm not sure what you mean here. Each time you open a php://memory
stream, you're working on a new bucket, right?
Yes exact. My bad. But my proposal still persist. Identifying
php://memory buckets would be nice to retrieve them. For example:
$f1 = fopen('php://memory/foo', 'r+');
fwrite($f1, 'foobar');
unset($f1);
$f1prime = fopen('php://memory/foo', 'r+');
rewind($f1);
var_dump(stream_get_contents($f1)); // string(6) foobar
Is it interesting? In this way, we have a similar behavior than
php://fd/i, file://, http:// etc.
No. When you do unset($f1), you're closing the file and the memory is
reclaimed. That's how it's supposed to be.
Just pass the stream along. If you really need to use operations on the
URLs themselves, you can easily write a user wrapper that delegates to
static php://memory streams kept statically.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
On 31/01/13 15:35, Gustavo Lopes wrote:
On Thu, 31 Jan 2013 14:55:26 +0100, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
I'm not sure what you mean here. Each time you open a php://memory
stream, you're working on a new bucket, right?
Yes exact. My bad. But my proposal still persist. Identifying
php://memory buckets would be nice to retrieve them. For example:
$f1 = fopen('php://memory/foo', 'r+');
fwrite($f1, 'foobar');
unset($f1);
$f1prime = fopen('php://memory/foo', 'r+');
rewind($f1);
var_dump(stream_get_contents($f1)); // string(6) foobar
Is it interesting? In this way, we have a similar behavior than
php://fd/i, file://, http:// etc.
No. When you do unset($f1), you're closing the file and the memory is
reclaimed. That's how it's supposed to be.
Ok.
Just pass the stream along. If you really need to use operations on
the URLs themselves, you can easily write a user wrapper that
delegates to static php://memory streams kept statically.
That's what I did.
Thank you for the clarification.
--
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
[PHP-DEV] PHP 5.3.22RC1 and 5.4.12RC1 Released for Testing!
Hi! We've released PHP 5.3.22RC1 and 5.4.12RC1 which can be found here: 5.3.20RC1: http://downloads.php.net/johannes/php-5.3.22RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.22RC1.tar.gz 5.4.10RC1: http://downloads.php.net/stas/php-5.4.12RC1.tar.bz2 http://downloads.php.net/stas/php-5.4.12RC1.tar.gz Windows binaries for both, as always, are at: http://windows.php.net/qa/ These are regular bugfix releases, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. If no critical issues is found in this RC, the final version will be released in two weeks. Regards, Stas Malyshev, Johannes Schlüter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 01/31/2013 01:22 AM, Terry Ellison wrote:
On 30/01/13 00:54, Rasmus Lerdorf wrote:
On 01/29/2013 04:47 PM, Stas Malyshev wrote:
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script may be compiled in one environment but
loaded in another, which may create difference in class tables,
especially combined with early binding for inherited classes. Getting
rid of it is not that easy until people stop writing code like:
if($foo) return;
class Foo extends Bar {}
which would work differently depending on if Bar is defined or not.
Yes, I am quite familiar with it since we had to handle this in APC too.
But I don't think getting rid of it is that hard. It obviously can't be
done in the opcode cache because by the time the compiler hands us the
op_array we have already lost the FETCH_CLASS opcode which we may or may
not need. We need to look at whether that MAKE_NOP() call in the
compiler is actually a worthwhile optimization in a future where most
people will be running an opcode cache by default.
This is one of the prime examples of making the compiler more opcode
cache friendly. Yes, it may be at the slight expense of non-opcode cache
performance, but with a bundled opcode cache implementation that should
be less of a worry.
+1. This one makes no sense to me as it simply hoists the
zend_do_inheritance() from runtime binding to compile-time, and this
binding has to be backed out by any opcode cache to work properly. It
might save a few microseconds per class declaration in non-cached
performance, but add factors more to cached performance. Why do this?
I agree. And the code doesn't have to be as silly as the example Stas
gave. Something as simple as this will hit it:
indexA includes child1 and child2 which both extend parent1
indexB includes only child2
Assuming these are all in different files, if you hit indexA first, by
the time the compiler gets to child2 parent1 already exists because
child1 inheriting from it brought it in so it will be compiled without
the FETCH_CLASS opcode.
But then you hit the indexB entry point and now the compiled child2 is
used in a context that doesn't already provide parent1 so the cached
opcodes can't be used here.
Of course, if on an empty cache the indexB entry point is hit before the
indexA entry point, then everything is fine. child2 will be compiled
with the FETCH_CLASS parent1 intact and this version can be used in
both contexts.
This is the kind of thing I really don't want to have to explain to
people with an integrated cache solution. It is a level of detail the
user should never hit.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: alejosimon
VCS Account Rejected: alejosimon rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Reflection] Improve logic of ReflectionMethod-invokeArgs() for static methods
Maybe I can help explain a good example on were this is useful as I also
suggested this improvement and created the patch for it:
(http://bugs.php.net/bug.php?id=62113)
This is actually something I am using in one of my primary projects as a
framework (this example shows the concept not the actual code I am using). This
allows you to create new Models and extend (using traits) the specific
functions you'd like to attach to each extended model class.
/* Was a bit large so I posted here */
https://gist.github.com/4685694
There is a workaround so it was not super important for me to push for it to be
implemented (see commented code from line: 13-24).
Full breakdown of what it does:
There is a primary Model abstract class which pre-defines and forces certain
functions and variables to be set. There are various traits set which a user
may define themselves that allow certain parts of the code to be hooked into
and modify it's behavior without having to re-declare the entire function. The
advantages to this is that it allows new Models to be added and extended
without having to worry about replacing an entire function and losing any
potential updates to the original function and gives the ability for multiple
traits to hook themselves into specific functions. In this example I have 2
traits, Check_Permissions and Log_Changes which both do a dummed down
version of their job... If a certain Model needs to be logged for when changes
happen it can just add the trait Log_Changes to it and it will auto-hook into
the update and create functions. If a certain model needs permission checks to
update or insert it can extend the Check_Permissions trait. (although in my
example one extends the after function hook and the other extends the
before function hook, the idea of why it'd be useful is good enough).
Although yes there is a workaround, the workaround requires a new closure to be
created for each function being executed every time. but if the
ReflectionMethod::invokeArgs() function would allow the first argument to be
a string of class or the object itself it wants to bind too it would save a new
closure from having to be created for every hook being executed.
(Sorry for the long code, but I wanted to make sure I got my point across on
why it'd be useful)
Software Developer
Nathan Bruer
-Original Message-
From: Alexander Lissachenko [mailto:lisachenko...@gmail.com]
Sent: Monday, January 14, 2013 2:16 PM
To: Sebastian Krebs
Cc: PHP internals list
Subject: Re: [PHP-DEV] [Reflection] Improve logic of
ReflectionMethod-invokeArgs() for static methods
Probably, it will be better to give a link to the one of examples of AOP
integration for laravel framework (requires 5.4.10 to work):
https://github.com/lisachenko/laravel-aspect (just clone, install dependencies
and look at result)
I need to perform weaving of aspects into the original methods, so here is an
example of generated source code:
?php namespace Illuminate\Foundation;
class AliasLoader__AopProxied {
// .. source code here
/**
* Get or create the singleton alias loader instance.
*
* @param array $aliases
* @return Illuminate\Foundation\AliasLoader
*/
public static function getInstance(array $aliases = array())
{
if (is_null(static::$instance)) static::$instance = new
static($aliases);
$aliases = array_merge(static::$instance-getAliases(),
$aliases);
static::$instance-setAliases($aliases);
return static::$instance;
}
/**
* Load a class alias if it is registered.
*
* @param string $alias
* @return void
*/
public function load($alias)
{
if (isset($this-aliases[$alias]))
{
return class_alias($this-aliases[$alias], $alias);
}
}
// more source code here
}
class AliasLoader extends AliasLoader__AopProxied {
/**
*Property was created automatically, do not change it manually
*/
private static $__joinPoints = array();
// some source code here
/**
* Get or create the singleton alias loader instance.
*
* @param array $aliases
* @return Illuminate\Foundation\AliasLoader
*/
public static function getInstance(array $aliases = array())
{
return
self::$__joinPoints['static:getInstance']-__invoke(get_called_class(),
array($aliases));
}
/**
* Load a class alias if it is registered.
*
* @param string $alias
* @return void
*/
public function load($alias)
{
return self::$__joinPoints['method:load']-__invoke($this,
array($alias));
}
// some source code here
}
You can notice, that original class name is pointing to the decorator class
after weaving. Source code still use
Re: [PHP-DEV] rfc:foreach-non-scalar-keys
I'm not sure how I came to that conclusion - did the description change
since I looked at it?
I guess the title foreach-non-scalar-keys may have thrown me off - so
this isn't about arrays, or really even about foreach, but about the
Iterator interface. I'm not against that at all.
I would suggest considering the addition of a second, distinct interface -
rather than a modification to the existing interface, which already does
what it's supposed to and works well, including the warning, which is
appropriate for the intended use of that interface with the foreach
statement.
This alternative interface could have the opposite behavior - issuing a
warning if the returned key is not an object. I don't think there's a
legitimate use-case where mixing scalar and object keys would be a good
idea? (if there were, a single interface might be the only way to go.)
On Tue, Jan 29, 2013 at 8:34 AM, Etienne Kneuss col...@php.net wrote:
This RFC is not about arrays.
The proposed change is to allow Iterator::key() to return things other
than int/strings. Consequently, it would mean foreach($iterable as
$key=$foo) { $key can be an object here }.
SplObjectStorage solves it by returning an array() of
object-key/object-data as *value*, and an integer as key, which is not
ideal.
Best,
On Tue, Jan 29, 2013 at 2:15 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Rasmus,
Relax. It hasn't even been proposed yet. Give the author some time to
finish the RFC before proposing it here, and then we can discuss it...
Anthony
On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz ras...@mindplay.dk
wrote:
I just saw this RFC:
https://wiki.php.net/rfc/foreach-non-scalar-keys
By non-scalar, presumably we're talking about objects? In the numbers
that e.g. resources typically get used, having a collection indexed by
resources would seem like an extremely exotic need.
Moreover, we already have this:
http://php.net/manual/en/class.splobjectstorage.php
I just want to note that, while allowing non-scalar keys may seem like a
natural addition, we're not talking about a simple change to the foreach
statement - we're talking about a fundamental change to the array type.
So I will point out two things:
1. Allowing non-scalar keys in arrays takes away an error-condition that
would normally be reported: accidentally using an object as a key (which
could even work in some cases, and could cause objects not to be garbage
collected.)
2. SplObjectStorage already solves this problem - minus e.g. resources,
but
you could put your resources in an object and address that (very exotic)
need.
Bottom line, I'm not in favor of this idea - it just doesn't seem
necessary
or really even beneficial to me.
- Rasmus Schultz
--
Etienne Kneuss
http://www.colder.ch
Re: [PHP-DEV] rfc:foreach-non-scalar-keys
On Fri, Feb 1, 2013 at 1:05 AM, Rasmus Schultz ras...@mindplay.dk wrote: I'm not sure how I came to that conclusion - did the description change since I looked at it? I guess the title foreach-non-scalar-keys may have thrown me off - so this isn't about arrays, or really even about foreach, but about the Iterator interface. I'm not against that at all. I would suggest considering the addition of a second, distinct interface - rather than a modification to the existing interface, which already does what it's supposed to and works well, including the warning, which is appropriate for the intended use of that interface with the foreach statement. This alternative interface could have the opposite behavior - issuing a warning if the returned key is not an object. I don't think there's a legitimate use-case where mixing scalar and object keys would be a good idea? (if there were, a single interface might be the only way to go.) Please, don't make this more complicated than it is. This is just about removing an arbitrary engine limitation. And yes, obviously mixing different keys has applications, e.g. consider implementing a generalized hash type. It makes no sense whatsoever to implement the same thing with two classes implementing different interfaces. The only reason why this needs discussion is that allowing non string/int keys requires a change in the internal iterator API. Nikita
Re: [PHP-DEV] rfc:foreach-non-scalar-keys
I'm not sure how I came to that conclusion - did the description change since I looked at it? Maybe a little bit but not very much, if at all. I guess the title foreach-non-scalar-keys may have thrown me off - so this isn't about arrays, or really even about foreach, but about the Iterator interface. I'm not against that at all. Actually, this is ENTIRELY about foreach. You can currently return an object as a key from an iterator with no problems if you call the method. The problem is that the foreach code takes that value and coerces it to a string or integer. In the case of objects and arrays as keys it fails. We want the foreach to leave it alone and simply allow us to expose the key as an object or array. I would suggest considering the addition of a second, distinct interface - rather than a modification to the existing interface, which already does what it's supposed to and works well, including the warning, which is appropriate for the intended use of that interface with the foreach statement. Having multiple interfaces that the engine uses to iterate in a foreach sounds like a bad idea to me. It's complicated enough as it currently is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 01/30/2013 06:47 AM, Zeev Suraski wrote: This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', This section extremely general and doesn't explain what the expected feature set might look like. I'm not asking for absolute certainties, just a technical description of what is and isn't the goal. Is it the complete Optimizer+, are there potential cleanups, do you see it being enabled (if not in PECL) or disabled by default, etc. Did I miss seeing the link to the current optimizer+ documentation? http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html (thanks Rasmus) Your email comment to John Carter about Zend Guard decoder is also not (yet) in the RFC. Chris and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
