Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <CAM+1YOz823PCdixmWorg3c37Z3LazcFQ7FHYoKg_Z_tEaw+=QA@mail.gmail.com> <CAM+1YOxUo9M3X5+v+Cpaf7MAfEK8dkPPRPMTvY16PadHKr1y8g@mail.gmail.com> <529642F1.8090506@ajf.me> <CAM+1YOxnzF9C6fA9XsCzJ5GcoiZJ76nujwp3Pt8iVUA7a=K0dQ@mail.gmail.com>
Date: Thu, 19 Dec 2013 13:03:01 +0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.w8b0rby1c9evq2@nikita2206-n56vj>
In-Reply-To: <CAM+1YOxnzF9C6fA9XsCzJ5GcoiZJ76nujwp3Pt8iVUA7a=K0dQ@mail.gmail.com>
User-Agent: Opera Mail/12.16 (Linux)
Subject: Re: [PHP-DEV] Re: RFC Proposal: New assign value operator
From: inefedor@gmail.com ("Nikita Nefedov")

On Thu, 19 Dec 2013 00:32:14 +0400, 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!


I don't like that your examples embrace mutability for objects which  
clearly are immutable.