Re: [PHP-DEV] PHP 5.3.0RC3
Matt Wilmas wrote: Hint: zend_operators.* (I noticed your recent cleanup stuff, and thought He has to notice.) I forgot smiley from that. This was more tongue-in-cheek than a real rant. :D much either way, but that sounds nice. :O)). I'd vote for karma removal until people can learn to do stuff correctly; you'd probably agree. Yes please, but I do want to give chance for people to correct their mistakes before that happens. ;) [1] http://realplain.com/php/is_numeric.diff Yup, that's still missing from HEAD. I'll merge it myself if nobody beats me to it, but I hope you could review the code afterwards so we can be sure it got in clean. One can't really rely on the tests on this since there are so many tests failing in HEAD at the moment.. Anyway, everyone: PLEASE commit to HEAD first. I know it's painful and not always that easy, but in the long run it makes all our lives much easier by making applying patches between branches actually possible. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi Guilherme, 5.3 is closed for major updates (it is in RC state). I would try to look into this when we develop a strategy for next PHP version. Thanks. Dmitry. Guilherme Blanco wrote: Hi guys, What's the status on this one?! It's an important optimization that should be considered. Save more than a million method calls on a framework does not worth? None gave a final word on this subject. I could not see this commited in 5.3 neither in HEAD. So...can someone notify me about the status of this??? Cheers, On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote: Marcus Boerger wrote: Aren't we able to bind these at least partially to the function call opcode, in case we know they are constant? If all is constsnt we could even store the whole lookup in the opcode. Well you'd have to convince Zend to do that because os far they have always been against this approach. We can't modify opcode it self as it'll break opcode caches. However we can introduce some indirect table associated with op_array, which can be used to implement inline caches without direct opcode modification (in the same way as IS_CV variables work). There are a lot of papers about polymorphic inline caches (e.g. http://research.sun.com/self/papers/pics.html) which we probably should use to not to invite bicycle. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi Paul, Paul Biggar wrote: On Mon, May 11, 2009 at 7:47 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: What's the status on this one?! I think it died from neglect. But it was a really good idea. One question that was raised was: On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote: However we can introduce some indirect table associated with op_array, which can be used to implement inline caches without direct opcode modification (in the same way as IS_CV variables work). There are a lot of papers about polymorphic inline caches (e.g. http://research.sun.com/self/papers/pics.html) which we probably should use to not to invite bicycle. You can't actually use PICs or even ICs with the Zend engine, because you can't insert code into the callee method's header (you would need a JIT). You also wouldn't want to, since PHP can't use the recompilation techniques that Self had. You can use lookup caches, which is exactly what the original patch was. I know PHP limitations, and I meant additional lookup caches for one or few results connected directly to ZEND_INIT_METHOD_CALL (and family) opcodes. FWIW, since PHP has a static inheritence chain, the best approach seems to be to build a virtual dispatch table, instead of a hashtable for functions. However, there might be some esoteric extensions which make this difficult. The real things is even worse as during compilation of a class it's parent class doesn't have to be known. So construction of VMTs becomes a bit problematic. BTW we could think in this way... Thanks. Dmitry. Paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Reflection
Hi Johannes
2009/5/11 Johannes Schlüter johan...@php.net:
(re-sending, sorry if this arrives twice)
Hi,
This should be low risk as it's a self-contained function and we all est
HEAD ... but I'd prefer not adding anything but bug fixes to 5.3 as it
already took way too long.
We can always just merge it in 5.3.1 if your fine with it, seems
stupid to have a method there in a branch which isn't anywhere soon
(but hopefully im wrong), but nonetheless.
Didn't take a look at the code so can't say much
At least getClosureThis() depends on $this handling which was reverted
from 5.3.
Not sure what getClosure() does.
As said on irc, then yea getClosure() can be used to create a closure
of the function instance:
function greet($who) {
echo 'Greetings ' . $who;
}
$rf = new ReflectionFunction('greet');
$greet = $rf-getClosure();
$greet('Johannes');
I will have a look and reply to Christians mail once I've read and
understood the $this handling with closures, but I sort of see why its
not reverted there yet.
We have no real namespace meta-data available, the only way doing things
there would be by iterating over the class table and parsing the class
names. Not usre that's really a good thing to do.
It just seems odd that we have reflection for almost class, function
etc. elements but not namespaces, whereas it could be so simple as:
class ReflectionNamespace {
public $name;
public $absolute_path;
public function __construct($absolute_path_or_inherited_name);
ReflectionClass[] public function getClasses();
ReflectionFunction[] public function getFunctions();
array public function getConstants();
int public function getLine();
string public function getFile();
bool public function isAutoLoaded();
/* etc */
}
And then change inNamespace() to return:
ReflectionNamespace public function inNamespace()
or add an additional parameter/method to do so.
I was under the impression this was possible, or is it only printed by
export()?
I see it being printed in _extension_string(), but I don't see any
other references to how you may obtain that value. But if you like I
can add it (perhaps together with getDefaultValue) in 5.3.1.
I don't think this belongs to that class as these values should match
the one PHP was compiled with, so I think this should be a global
function.
After looking some more on it, then I agree, however the
isDynamicLoaded might be somewhat useful.
johannes
--
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi Stas, Dmitry, On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev s...@zend.com wrote: IHMO it's not static enough. I.e., since PHP is not compiled, we can not create VD table for the class until runtime inheritance, which means that the code using this class can use method resolution more efficient than name-function, i.e. hashtable. These lookups can be cached (i.e. CV style) but I don't see how they can be altogether prevented. On Tue, May 12, 2009 at 7:25 AM, Dmitry Stogov dmi...@zend.com wrote: The real things is even worse as during compilation of a class it's parent class doesn't have to be known. So construction of VMTs becomes a bit problematic. BTW we could think in this way... 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? In the worst case, it _might_ be cheaper to build it at instantiation time, but I would have to look up how expensive that is in a more static language to be sure. Certainly, it is currently so expensive that almost anything else would be better (including the OP's patch). 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] Method call improvements
Paul Biggar wrote: Hi Stas, Dmitry, On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev s...@zend.com wrote: IHMO it's not static enough. I.e., since PHP is not compiled, we can not create VD table for the class until runtime inheritance, which means that the code using this class can use method resolution more efficient than name-function, i.e. hashtable. These lookups can be cached (i.e. CV style) but I don't see how they can be altogether prevented. On Tue, May 12, 2009 at 7:25 AM, Dmitry Stogov dmi...@zend.com wrote: The real things is even worse as during compilation of a class it's parent class doesn't have to be known. So construction of VMTs becomes a bit problematic. BTW we could think in this way... 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? The parent class may be defined in other file that is loaded at runtime using include() statement. It's very usual case. So the PHP first loads the include file and then declares child class at runtime. Must it be known for the class' first instantiation? Of course. :) In the worst case, it _might_ be cheaper to build it at instantiation time, but I would have to look up how expensive that is in a more static language to be sure. Certainly, it is currently so expensive that almost anything else would be better (including the OP's patch). I don't see how run-time VMT contraction may help, because calls to virtual method must know VMT offset at compile-time. Thanks. Dmitry. Thanks, Paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov dmi...@zend.com wrote: 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? The parent class may be defined in other file that is loaded at runtime using include() statement. It's very usual case. So the PHP first loads the include file and then declares child class at runtime. Must it be known for the class' first instantiation? Of course. :) On Tue, May 12, 2009 at 7:25 AM, Dmitry Stogov dmi...@zend.com wrote: The real things is even worse as during compilation of a class it's parent class doesn't have to be known. So construction of VMTs becomes a bit problematic. BTW we could think in this way... OK, so I dont understand this exactly. Is it correct to say that if a class uses inheritance its compilation will be deferred until its first instantiation? Or is it compiled when it is seen, and its parent backpatched in later. When is later? But I think its fair to say that it has static inheritance - that is, its full inheritance chain is known before it can be instantiated, and it can never be changed after that. In the worst case, it _might_ be cheaper to build it at instantiation time, but I would have to look up how expensive that is in a more static language to be sure. Certainly, it is currently so expensive that almost anything else would be better (including the OP's patch). I don't see how run-time VMT contraction may help, because calls to virtual method must know VMT offset at compile-time. Right. Construction is fine. Their use is not. I don't know what I was thinking. So it looks like the best way forwards is still the OP's patch? 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] PHP 5.3.0RC3
On 12.05.2009, at 04:20, Matt Wilmas wrote: Hi Lukas, - Original Message - From: Lukas Kahwe Smith Sent: Monday, May 11, 2009 [...] Critical issues: 1) I assume the issues with rounding are resolved. If any issues pop up again, please let the list know. @Matt/Dmitry: Can you just give us the quick nod that all is well here? No, can't say that all is well. :-/ Nothing was changed yet, sorry if you misunderstood. (BTW, it's not rounding/parsing, but conversion/casting of floats-integers... :-)) Doh. Would have been nice if someone could have alerted us about this ahead of RC2. So it goes. I sent the updated patch a month ago, and then the next week Stas asked some questions off-list, for clarification, etc. and then said that the patch looks good and since it appears to fix things I think it can be applied. That's the only feedback I had really, and Dmitry mentioned that it breaks about 30 tests (I'd consider them broken now, to match the code, however ;-)), which I knew would have to be updated. I didn't try to fix them yet, since I didn't know if the changes would finally be applied or not. I was going to bring it up again but then it was too close to RC2. There were some e-mails on the subject that I didn't follow up on (nothing major, just comments), including one of yours I think. Anyway, I guess I/we can wonder about RC3 now? Again, the *very minor* modifications only help to ensure the [usual] long-standing behavior on all platforms -- e.g. most users would see no change from 5.2 or prior. @Stas/Dmitry: ? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Paul Biggar wrote: On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov dmi...@zend.com wrote: 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? The parent class may be defined in other file that is loaded at runtime using include() statement. It's very usual case. So the PHP first loads the include file and then declares child class at runtime. Must it be known for the class' first instantiation? Of course. :) On Tue, May 12, 2009 at 7:25 AM, Dmitry Stogov dmi...@zend.com wrote: The real things is even worse as during compilation of a class it's parent class doesn't have to be known. So construction of VMTs becomes a bit problematic. BTW we could think in this way... OK, so I dont understand this exactly. Is it correct to say that if a class uses inheritance its compilation will be deferred until its first instantiation? Or is it compiled when it is seen, and its parent backpatched in later. When is later? The classes which parent isn't known during compilation inherited at run-time by DECLARE_INHERITED_CLASS opcode. It patches property and method tablas, checks for method compatibility, etc But I think its fair to say that it has static inheritance - that is, its full inheritance chain is known before it can be instantiated, and it can never be changed after that. Right, but it has a lot of dynamic issues anyway. E.g. parent class may be changed or loaded from different file. Thanks. Dmitry. In the worst case, it _might_ be cheaper to build it at instantiation time, but I would have to look up how expensive that is in a more static language to be sure. Certainly, it is currently so expensive that almost anything else would be better (including the OP's patch). I don't see how run-time VMT contraction may help, because calls to virtual method must know VMT offset at compile-time. Right. Construction is fine. Their use is not. I don't know what I was thinking. So it looks like the best way forwards is still the OP's patch? Thanks, Paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
On Tue, May 12, 2009 at 12:29 PM, Dmitry Stogov dmi...@zend.com wrote: But I think its fair to say that it has static inheritance - that is, its full inheritance chain is known before it can be instantiated, and it can never be changed after that. Right, but it has a lot of dynamic issues anyway. E.g. parent class may be changed or loaded from different file. This is what I'm getting at. How can the parent class be changed? I can see that it might be deferred, but I don't see how it can be changed once it's set. 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] Method call improvements
Thanks Dmitry, I imagined that. I just thought it was already applied, but it's not. So I spoke a bit with Lukas and he suggested me to revamp this discussion, since it stopped all of a sudden. Anyway... once you guys find a final patch, should I expect it at least commited into HEAD? Cheers, On Tue, May 12, 2009 at 3:08 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Guilherme, 5.3 is closed for major updates (it is in RC state). I would try to look into this when we develop a strategy for next PHP version. Thanks. Dmitry. Guilherme Blanco wrote: Hi guys, What's the status on this one?! It's an important optimization that should be considered. Save more than a million method calls on a framework does not worth? None gave a final word on this subject. I could not see this commited in 5.3 neither in HEAD. So...can someone notify me about the status of this??? Cheers, On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote: Marcus Boerger wrote: Aren't we able to bind these at least partially to the function call opcode, in case we know they are constant? If all is constsnt we could even store the whole lookup in the opcode. Well you'd have to convince Zend to do that because os far they have always been against this approach. We can't modify opcode it self as it'll break opcode caches. However we can introduce some indirect table associated with op_array, which can be used to implement inline caches without direct opcode modification (in the same way as IS_CV variables work). There are a lot of papers about polymorphic inline caches (e.g. http://research.sun.com/self/papers/pics.html) which we probably should use to not to invite bicycle. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The constant use of isset()
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) 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
Re: [PHP-DEV] The constant use of isset()
So if the variable is set and contains false, we can't check it ? And near same problem for 0, empty array and empty string. But you can also use this syntax : (yes it's not very clean) if( @$_GET['foo'] === 'bar') or if( @$_GET['foo'] === 'bar' or @$_GET['baz'] === 'bat' ) Olivier Ólafur Waage a écrit : 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) 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
So if the variable is set and contains false, we can't check it ? And near same problem for 0, empty array and empty string. How would you ever get false (the value, not the string) into a request variable? (without setting it that way after the request init, that is) S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
Sean Coates a écrit : So if the variable is set and contains false, we can't check it ? And near same problem for 0, empty array and empty string. How would you ever get false (the value, not the string) into a request variable? (without setting it that way after the request init, that is) So this isset() behavior will only be available for request variable, not for all variables ? I can't do that ? $a = isset($foo['bar']) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
The error suppression was discussed in the rfc and yes it is not clean and you could be suppressing something else inadvertently. Yes the false value would be an issue with this, but for 0, empty array and empty string is an issue with just about anything else in PHP already. Hence === if you want to be strict with it. 2009/5/12 Olivier B. php-dev.l...@daevel.net So if the variable is set and contains false, we can't check it ? And near same problem for 0, empty array and empty string. But you can also use this syntax : (yes it's not very clean) if( @$_GET['foo'] === 'bar') or if( @$_GET['foo'] === 'bar' or @$_GET['baz'] === 'bat' ) Olivier Ólafur Waage a écrit : 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
Re: [PHP-DEV] The constant use of isset()
So this isset() behavior will only be available for request variable, not for all variables ? I'm not picking sides, but that seems to me like the overwhelmingly popular use case. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
Regarding ifsetor, what's wrong with just using this: isset($myvar) OR $myvar = 'i am set'; It works in just the same way and has no problems. I agree it would be great though if there could be a function to retrieve a variable's value if it exists, without throwing an error if it doesn't exist. I'm not sure if isset would be appropriate though. Lewis. 2009/5/12 Ólafur Waage olaf...@gmail.com: 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) 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
Regarding ifsetor, what's wrong with just using this:
isset($myvar) OR $myvar = 'i am set';
It works in just the same way and has no problems. I agree it would be
great though if there could be a function to retrieve a variable's
value if it exists, without throwing an error if it doesn't exist. I'm
not sure if isset would be appropriate though.
Maybe the internal implementation of array access should be changed so
that a key that is not
set or has its value equal to null, should return null. This is almost
the behavior we have right now:
php -r $a = array('x' = null); var_dump(isset($a['x']));
bool(false)
php -r $a = array('x' = null); var_dump($a['x']);
NULL
However, the above case does not issue a notice.
Lewis.
2009/5/12 Ólafur Waageolaf...@gmail.com:
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)
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
On Tue, 2009-05-12 at 18:23 +0100, Lewis Wright wrote:
Regarding ifsetor, what's wrong with just using this:
isset($myvar) OR $myvar = 'i am set';
It works in just the same way and has no problems. I agree it would be
great though if there could be a function to retrieve a variable's
value if it exists, without throwing an error if it doesn't exist. I'm
not sure if isset would be appropriate though.
Lewis.
mixed value_of( $variable [, $defaultValue=null] );
?php
if( value_of( $_GET['action'] ) == 'edit' )
{
// ...
}
switch( value_of( $_GET['action'], 'details' ) )
{
case 'details': ...
}
?
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
Ó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) 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. Yes. Beaten it has been. I still want my function: filled(...). I described the spec here: http://marc.info/?l=php-internalsm=114677154729359w=2 You would use it like the opposite of empty but it takes an arbitrary number of parameters and returns the first value where empty() would evaluate as false. Like isset() and empty(), it would do so without throwing any notices: $x = filled($y[maybe], $obj-tryit, $z['a']['b']['c'], $default); Would it be a timesaver and very useful? You bet! That was 2006. Good luck getting anything changed. -- Dante -- D. Dante Lorenso da...@lorenso.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
Hi! @Stas/Dmitry: ? As I said, I'm ok with committing this, provided all the tests are fixed, etc. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
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. 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. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi Paul:
On Tue, May 12, 2009 at 12:50:12PM +0100, Paul Biggar wrote:
This is what I'm getting at. How can the parent class be changed? I
can see that it might be deferred, but I don't see how it can be
changed once it's set.
The decision of which class to extend from can be made at run time:
- main.php -
?php
$direction = true;
if ($direction) {
include './core1.php';
} else {
include './core2.php';
}
class ext extends core {
}
$o = new ext;
$o-func();
exit;
- core1.php -
?php
class core {
public function func() {
echo __FILE__ . \n;
}
}
- core2.php -
?php
class core {
public function func() {
echo __FILE__ . \n;
}
}
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] The constant use of isset()
-Original Message-
From: Ólafur Waage [mailto:olaf...@gmail.com]
Sent: 12 May 2009 17:35
To: internals@lists.php.net
Subject: [PHP-DEV] The constant use of isset()
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)
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
Use array_merge to provide default values...
$get = array_merge($_GET, array('foo' = 'bar', 'baz' = 'bat));
If ($get['foo'] == 'bar' || $get['baz'] == 'bat')
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The constant use of isset()
On Tue, May 12, 2009 at 5:39 PM, Robert Cummings rob...@interjinn.comwrote:
On Tue, 2009-05-12 at 18:23 +0100, Lewis Wright wrote:
Regarding ifsetor, what's wrong with just using this:
isset($myvar) OR $myvar = 'i am set';
It works in just the same way and has no problems. I agree it would be
great though if there could be a function to retrieve a variable's
value if it exists, without throwing an error if it doesn't exist. I'm
not sure if isset would be appropriate though.
Lewis.
mixed value_of( $variable [, $defaultValue=null] );
?php
if( value_of( $_GET['action'] ) == 'edit' )
{
// ...
}
switch( value_of( $_GET['action'], 'details' ) )
{
case 'details': ...
}
?
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
Will this run without notices if the value you are passing to the function
isnt set?
Olafur
Re: [PHP-DEV] The constant use of isset()
On Tue, 2009-05-12 at 19:35 +, Ólafur Waage wrote:
On Tue, May 12, 2009 at 5:39 PM, Robert Cummings rob...@interjinn.comwrote:
On Tue, 2009-05-12 at 18:23 +0100, Lewis Wright wrote:
Regarding ifsetor, what's wrong with just using this:
isset($myvar) OR $myvar = 'i am set';
It works in just the same way and has no problems. I agree it would be
great though if there could be a function to retrieve a variable's
value if it exists, without throwing an error if it doesn't exist. I'm
not sure if isset would be appropriate though.
Lewis.
mixed value_of( $variable [, $defaultValue=null] );
?php
if( value_of( $_GET['action'] ) == 'edit' )
{
// ...
}
switch( value_of( $_GET['action'], 'details' ) )
{
case 'details': ...
}
?
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
Will this run without notices if the value you are passing to the function
isnt set?
No, I was suggesting a format for the desired functionality (I should
have been more clear). IMHO the above would be the perfect solution if
it worked in the same manner as isset() (i.e. doesn't generate notices).
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
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 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? 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[]=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
