Hi, > 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.
I'm lately using @$var["key"] a lot (despite it's slowness) and I like it a lot. It makes most code a lot more readable. I would be +1 for it, if we can make it fast. I think most people (me included) want only to avoid the notice for accessing undefined array offsets. What if we just remove the notice for accessing undefined array offsets, because it's the most common use case? I've looked a bit into other languages (Ruby, Python, Go) and all of them do not generate an error when an undefined dict/hash/map key is accessed. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH Am Samstag, 21. Juli 2012 um 01:10 schrieb Stas Malyshev: > 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. > > > -- > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
