Re: [PHP-DEV] Method call improvements
Hi Stas, On Tue, May 12, 2009 at 7:24 PM, Stanislav Malyshev s...@zend.com wrote: Hi! Apologies, I'm not familiar with run-time inheritence in PHP. My understanding was that when a classes source code is compiled, its parent classes must be known. When is this not the case? Must it be known for the class' first instantiation? No, the problems here are different. The process works as follows: 1. Class X source is compiled. 2. X is added to the class table 3. Class Y (extends X) source is compiled. 4. Since Y extends X, methods of X are added to methods of Y 5. Y is added to the class table Now, adding bytecode caching. Bytecode caching replaces steps 1 and 3 with loaded from cache - however since the identity of X can change between requests, what is stored for step 3 can not bind to X as it is now - for that there's step 4 which is executed at runtime, when the line where class is defined is executed. That means static table describing class Y can exist only after step 4, and it is not cacheable beyond the bounds of one request. Great explanation, thank you. As far as terminology goes, this is still static inheritance, as you cannot change a class' parent after it has been set in a request. Run-time inheritance is where it can change, for example in Javascript where an object's prototype can be changed. I think you could do lookup caches (ie the OP's patch) either way, but its probably cheaper with static inheritance. However, if we now are compiling the code such as: $a-foo(); we meet with following challenges: 1. We do not know what class $a is (suppose it's X, but in most cases we won't know that) 2. If we did, we do not know what class X is (definition, as opposed to just name) at the compile time (it could be defined later) 3. If we knew what class X definition is at compile time, the above would preclude us from generating any code that binds to that definition since such code would not be cacheable. These are three independent challenges, without overcoming each of them I do not see how virtual table would be helpful. Yes. As I replied to Dmitry, I clearly wasn't thinking when I suggested this. FYI, I do type-inference on PHP, and the types here are difficult to calculate in the general case. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
2009/5/12 Ionut Gabriel Stan ionut.g.s...@gmail.com
2009/5/13 Ólafur Waage olaf...@gmail.com:
2009/5/12 Brian Moon br...@moonspot.net
$foo = filter_input(INPUT_GET, foo, FILTER_UNSAFE_RAW);
That would have a value if set or null if not set. It also allows you
to
validate it using filters if you wanted to. This of course only works
with
GPC variables, but it is a great solution.
Brian.
http://brian.moonspot.net/
Can this be turned into a userland function?
If you're interested in userland code, then you have two solutions:
1. Make functions like GET, POST, COOKIE, SESSION and use them instead
of the superglobals (functions are superglobal). An example:
// PHP 5.3
function GET($key, $default = null) {
return isset($_GET[$key]) ? $_GET[$key] : $default;
}
// PHP = 5.3
function GET($key, $default = null) {
return isset($_GET[$key]) ?: $default;
}
2. Use ArrayObject to override the superglobals in an auto_prepend_file:
-
$_GET = ArrayObject($_GET);
Anyway, these will save the trouble with the superglobals, not with
ordinary arrays.
Yes this will work with GPC variables but not with any other variable. And
passing values to it even feels right.
if(GET(foo) == bar)
Olafur
On 5/12/09 11:35 AM, Ólafur Waage wrote:
While researching for this suggestion I found this rfc proposal
regarding
ifsetor() (
http://wiki.php.net/rfc/ifsetor?s[]=issethttp://wiki.php.net/rfc/ifsetor?s%5B%5D=isset
http://wiki.php.net/rfc/ifsetor?s%5B%5D=isset)
and it's rejection point was that it was currently not possible (
http://marc.info/?l=php-internalsm=108931281901389w=2 )
But would it be possible to check for a value of a variable if it is
set?
Since I often do (and see others do)
if(isset($_GET[foo]) $_GET[foo] == bar)
or even worse
if((isset($_GET[foo]) $_GET[foo] == bar) ||
(isset($_GET[baz])
$_GET[baz] == bat))
to be able to do something like this
if(isset($_GET[foo]) == bar)
or
if(isset($_GET[foo]) == bar || isset($_GET[baz]) == bat)
That isset (or some other language construct) would return the variable
if
it were set and false if it was not.
Thanks for your time, i know this has probably been talked to death in
one
form or other.
Ólafur Waage
olaf...@gmail.com
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
Re: [PHP-DEV] PHP 5.3.0RC3
On 12.05.2009, at 20:12, Stanislav Malyshev wrote: Hi! @Stas/Dmitry: ? As I said, I'm ok with committing this, provided all the tests are fixed, etc. I do not know what the changes do. AFAIK they revert things to be more BC compliant with 5.2 and if that is the case, then there is no reason from an RM perspective to stop this change, if you guys feel its the right choice. If tests need fixing and you dont have the time for this, I am sure we will find people that do. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug #48256 readline crash
The readline extension links both libreadline and libhistory. This is unnecessary, and inspection of the readline example programs since version 2.0 implies that it has always been unnecessary. Both libraries include history.o, so linking to both gives you two copies of that module. The bug occurs when, due to operating system vagaries, libhistory loads before libreadline. This causes PHP's readline_add_history() to add history entries to libhistory's copy of the_history. Then when readline() is called, libreadline attempts to read the other copy of the_history. The result is a null pointer dereference in libreadline's previous_history() function. The solution is to remove all references to libhistory in ext/readline/config.m4. I have patched this in and tested it. This bug was closed as bogus on bugs.php.net due to some temporary short-circuit in the mind of a bug tracker admin. It's totally PHP's fault and there's nothing any distro can do to fix it. -- Tim Starling Index: ext/readline/config.m4 === RCS file: /repository/php-src/ext/readline/config.m4,v retrieving revision 1.25.2.3 diff -u -r1.25.2.3 config.m4 --- ext/readline/config.m4 28 Nov 2005 23:04:01 - 1.25.2.3 +++ ext/readline/config.m4 13 May 2009 06:06:13 - @@ -50,15 +50,6 @@ -L$READLINE_DIR/$PHP_LIBDIR $PHP_READLINE_LIBS ]) - PHP_CHECK_LIBRARY(history, add_history, - [ -PHP_ADD_LIBRARY_WITH_PATH(history, $READLINE_DIR/$PHP_LIBDIR, READLINE_SHARED_LIBADD) - ], [ -AC_MSG_ERROR(history library required by readline not found) - ], [ --L$READLINE_DIR/$PHP_LIBDIR $PHP_READLINE_LIBS - ]) - AC_DEFINE(HAVE_LIBREADLINE, 1, [ ]) elif test $PHP_LIBEDIT != no; then -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
