Re: 5.4's New De-referencing plus assignment

From: Date: Fri, 02 Dec 2011 17:05:07 +0000
Subject: Re: 5.4's New De-referencing plus assignment
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-56726@lists.php.net to get a copy of this message
That variable is used for getting error messages. Sent from my iPad On Dec 2, 2011, at 11:56 AM, Dmitri Snytkine <dsnytkine@ultralogistics.com> wrote: > IT would probably be even more convenient to just say > if( (new Validator())->isValid($value) ){ > > } > > No reason to just temporaraly assign $validator. > > > > Dmitri Snytkine > Web Developer > Ultra Logistics, Inc. > Phone: (888) 220-4640 x 2097 > Fax: (888) 795-6642 > E-Mail: dsnytkine@ultralogistics.com > Web: www.ultralogistics.com > > "A Top 100 Logistics I.T. Provider in 2011" > > > -----Original Message----- > From: Matthew Weier O'Phinney [mailto:weierophinney@php.net] > Sent: Friday, December 02, 2011 11:50 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] 5.4's New De-referencing plus assignment > > On 2011-12-01, Anthony Ferrara <ircmaxell@gmail.com> wrote: >> On Thu, Dec 1, 2011 at 12:34 PM, Ralph Schindler >> <ralph@ralphschindler.com> wrote: > <snip> >>> needs to somehow guarantee that all methods of the type $foo will return >>> $this. Â (BTW, this is not an argument for my feature as much as its an >>> argument as much as its one for "if we're going to do something, why not > do >>> it correctly in the first place".) Â The correct path here, IMO, would > be to >>> simply carry the expression result (since we're using '(' expr >>> ')' out > and >>> allow dereferencing on whatever comes out of it. >>> >> >> I would argue though that your syntax is completely possible today: >> >> $foo = new Foo; >> $foo->bar(); >> >> What's the reason to put that in a single line? Aside from terseness, >> is there any other benefit? With the new dereference, one benefit is >> that no variable is populated when none is needed. But in your case, >> you need both variables... > > Here's another example. > > We have validator classes. Typically, you call isValid() to see if a > value validates. If it does, you have no more use for the validator. If > it _doesn't_, however, you'll want to get the error messages. I could > see the following as being a nice, succinct way to use validators: > > if (!(($validator = new SomeValidator())->isValid($value))) { > // Validation failed, get messages... > $view->assign('errors' => $validator->getMessages()); > return $view->render('error'); > } > // validation passed, do something... > > Yes, this could be written as follows: > > $validator = new SomeValidator(); > if (!$validator->isValid($value)) { > // ... > } > // ... > > However, I can see some folks not really wanting that variable > declaration if they won't be using it outside the conditional. > > -- > Matthew Weier O'Phinney > Project Lead | matthew@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > -- > 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 >

« previous php.internals (#56726) next »