Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70734
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sclinternet.co.uk from 209.85.220.175 cause and error)
MIME-Version: 1.0
Sender: tom@sclinternet.co.uk
In-Reply-To: <CAM+1YOxnzF9C6fA9XsCzJ5GcoiZJ76nujwp3Pt8iVUA7a=K0dQ@mail.gmail.com>
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: Wed, 18 Dec 2013 20:45:35 +0000
Message-ID: <CAM+1YOyM0w9kuf_Y3k+LAYnD-3MwT3Qr8QKGk0TrEcp_u6W8Pg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2d3008289f004edd5206a
Subject: Re: [PHP-DEV] Re: RFC Proposal: New assign value operator
From: tom@scl.co.uk (Tom Oram)

--001a11c2d3008289f004edd5206a
Content-Type: text/plain; charset=ISO-8859-1

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
****************************************************

--001a11c2d3008289f004edd5206a--