Re: [PHP-DEV] The constant use of isset()

2009/5/12 Brian Moon > $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. > --

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 wrote: > > > 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

Re: [PHP-DEV] The constant use of isset()

On Tue, May 12, 2009 at 5:39 PM, Robert Cummings wrote: > 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 >

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.ph

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

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

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, v

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[]=isset) and it's rejection point was that it was currently not possible ( http://marc.info/?l=php-internals&

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

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

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.

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()

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)

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

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 Interna

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' ) Olivie

[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[]=isset) and it's rejection point was that it was currently not possible ( http://marc.info/?l=php-internals&m=108931281901389&w=2

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,

Re: [PHP-DEV] Method call improvements

On Tue, May 12, 2009 at 12:29 PM, Dmitry Stogov 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

Re: [PHP-DEV] Method call improvements

Paul Biggar wrote: On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov 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 define

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

Re: [PHP-DEV] Method call improvements

On Tue, May 12, 2009 at 9:43 AM, Dmitry Stogov 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 f

Re: [PHP-DEV] Method call improvements

Paul Biggar wrote: Hi Stas, Dmitry, On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev 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 resoluti

Re: [PHP-DEV] Method call improvements

Hi Stas, Dmitry, On Tue, May 12, 2009 at 2:01 AM, Stanislav Malyshev 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

[PHP-DEV] Re: Reflection

Hi Johannes 2009/5/11 Johannes Schlüter : > (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