Re: Re: RFC Proposal: New assign value operator

Oh and one final POiNT 6: class MyClass { private $x = 0; public function doActionA($value) { // do stuff $this->x = (int) $value; } public function doActionB($value) { // do different stuff $this->x = (int) $value; } } VS class MyClass { private $x = 0; public function doActionA($value) { // do stuff $this->x := $value; } public function doActionB($value) { // do different stuff $this->x := $value; } } Which is cleaner? In each case think how many changes are required to make $x a float instead of an int. Which maintains less risk of breaking by using the wrong time somewhere? That is all. Cheers, Tom On 18 December 2013 20:32, Tom Oram <tom@scl.co.uk> wrote: > > Sorry for the delay, I've been very busy. Before I let this go completely > I just want to give a couple of examples. I get the feeling I'm not going > to get anywhere with this but let me quickly just show a few things where I > think this would make life easier: > > POINT 1 (mixing types including scalars): > ------------- > Consider: > > $emails = array( > 'someone@hotmail.com', > new Email('bob@aol.com'), > new AdvancedEmail('alice@yahoo.com'), > ); > > Now which of these is a nicer way to clear all the addresses? > > foreach ($emails as &$email) { > if ($email instanceof Email) { > $email->setValue(''); > } elseif ($email instanceof AdvancedEmail) { > $email->setAddress(''); > } else { > $email = ''; > } > } > > OR > > foreach ($emails as &$emal) { > $email := ''; > } > > > POINT 2 (protecting against changing types): > ------------- > Consider a library provides a base class called Product like so > > class Product > { > protected $price = 0.0; > } > > Next up someone extends this class in their application > > class SpecialProduct > { > /** @var float $price */ > public function specialSetPrice($price) > { > $this->doSomethingSpecial(); > > $this->price = $price; > } > } > > Now the original library maintainers decide to use a value object for the > price changing Product to the following > > class Product > { > protected $price; > > public function __construct() > { > $this->price = new MoneyValue(0.0); > } > } > > At this point the original app developpers would have to update their > SpecialProduct so that > > $this->price = $price; > > becomes > > $this->price = new MoneyValue($price); > > HOWEVER if specialSetPrice had used > > $this->price := $price; > > from the start it would have adapted to any changes in type automatically > and therefore no modification would have had to be made. In fact the child > class didn't require any knowledge of the type defined in the parent. The > type is set once then used with not requirement to maintain consistency. > > > POINT 3 (it's nicer to use): > ------------- > I'm sorry but if you have a String class which you're using all over the > place > > $var := 'new value'; > > is so much more readable (to me at least) than > > $var->setValue('new value'); > > To those that argue it's confusing with =, it's not, it's a different > operator it's :=, just like +=, if you come across a new operator in the > code which you havent seen before you got and look it up and find out what > it does, just like if you see ** for the first time if the pow() RFC goes > through. > > And again if the designers decide to stop using a scalar and use an object > instead at some point all the assignments in the code won't have to be > fixed! > > > POINT 4 (argument against it can be done it other existing ways) > ------------- > Before foreach came along we used > > reset($array); > while (list($key, $value) = current($array)) { > next($array); > } > > So why did we need foreach? > > This RFC > > https://wiki.php.net/rfc/pow-operator?utm_content=buffer1f703&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer > suggests > a new ** operator which can be used instead of pow() > > Why do we need that? pow() works just fine! > > There are many many similar things in PHP's history and will be many more > i'm sure. Why did any of them get added? Because they make the code simpler > and easier to understand. I agree there's shouldn't be several ways to do > everything as it can lead to confusion and clutter but to say something is > no good because you can do it in another, more long winded way, I think is > a bit ridiculous. > > > Anyway, that's the last I'll say on it unless others show some interest. > But either way I'm interested to see what responses come back from this. > > Everyday I am coding I come across at least 2 or 3 instances where I want > to use something like this. > > Best regards to all, > Tom > > On 27 November 2013 19:07, Andrea Faulds <ajf@ajf.me> wrote: > >> On 27/11/13 09:36, Tom Oram wrote: >> >>> >>> Since writing the original message I've been looking at golang and found >>> that they have a := operation to infer type which is very similar to >>> what I >>> proposed. >>> >>> I'd like to try and start some discussion about this again as I think it >>> would be very useful and really open up the possibility of having objects >>> for primitive types. >>> >>> >> I'm not sure I understand the utility here. PHP has a dynamic typing >> system. The utility of := in languages like Go is that it allows you to >> avoid making a type declaration. But PHP does not have them anyway, so >> there it isn't useful in that case. >> >> -- >> Andrea Faulds >> http://ajf.me/ >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > **************************************************** > PLEASE NOTE: For support requests please > use support@scl.co.uk instead of emailing > staff directly, this way your request is likely to > be dealt with more efficiently. > **************************************************** > Tom Oram - SCL Internet Services > PO Box 8, Cardigan, Ceredigion, SA41 3YA > Website: http://www.scl.co.uk/ > Tel: +44 (0) 1239 622 411 > Fax: +44 (0) 1239 622428 > Company Reg. No. 2441708 > **************************************************** > -- **************************************************** PLEASE NOTE: For support requests please use support@scl.co.uk instead of emailing staff directly, this way your request is likely to be dealt with more efficiently. **************************************************** Tom Oram - SCL Internet Services PO Box 8, Cardigan, Ceredigion, SA41 3YA Website: http://www.scl.co.uk/ Tel: +44 (0) 1239 622 411 Fax: +44 (0) 1239 622428 Company Reg. No. 2441708 ****************************************************