Hi! > Top-posting, as not sure where to snip. :) > > I think either "??" "??:" as an operator makes sense, and would be > readable and easy to learn, and resolve any BC concerns people have. I'd > love to see this in, as the current behavior is basically useless for me > I don't think I've once had code where I could successfully use it > without worrying about the E_NOTICE, which then forces me to use the > longhand form. Having a version that does an implicit "isset" would be > tremendously useful.
I think we've painted ourselves into a corner somewhat here, because we have the following things clashing: 1. Producing an error when accessing non-existing var/element. 2. Unability to temporarily disable 1 since @ both is regarded as "unclean" and does not actually disable the error generation, only makes it not printed out. 3. Obvious need to express common pattern "take it if it exists, assume null if it does not". Note that the case in 3 is not limited to ?: in any way, you as frequently encounter it in any context where you can encounter a variable. We can get back to ?: if we extend 3 with "take it if it exists, assume this other value if it does not" - but we don't have to, as the use case is completely dominated by "null" pattern, it is very rare that you need any other default than null and type conversions of null like ''/false/0. I'd be very happy if we could have something like @$var['foo'] just work by not generating any errors, but if not then probably having some syntax saying "this variable or null, no notices" will be good - if say it's $?foo then we could easily add defaults by doing $?foo ?: 'bar'. Making @$var magically work though would have an advantage of being instantly backwards compatible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
