RFC Proposal: New assign value operator

The property is most likely private and you don’t have to bother about it anyway.

But yes, for pure PHP users it might seems confusing since PHP variables have no types. If you are familiar with types and operator overloading than it is more readable IMO

I assign the new price 29.99 to the variable $price

What’s wrong with that? Is quite straight forward no?

$price->setPrice(29.99); is straight forward as well IMO but your eyes need to read more than :=

Yet, as I said, it is a small benefit and without overloading of + - almost negligible.

With + - etc. it would be possible to do things like

$price += 1.50;

$price *= 2;

Etc.

IMO better readable than

$price->add(1.50);

$price->multiplyBy(2);

Cheers

Von: Peter Lind [mailto:peter.e.lind@gmail.com]
Gesendet: Mittwoch, 26. Juni 2013 14:00
An: Robert Stoll
Cc: Richard Quadling; Tom Oram; PHP internals
Betreff: Re: [PHP-DEV] RFC Proposal: New assign value operator

As far as I see it, it is kind of an operator overload mechanism for the assign operator.
This can be useful for small utility classes such as Money, Email etc.

An example was given:

$price = new MoneyValue();
$price := 29.99;

Instead of writing something like:
$price = new MoneyValue();
$price->setPrice(29.99);

The benefit is small, but can lead to better readable code.

Better readable code? It looks like you're reassigning $price, not assigning to a property of $price. If anything it is less readable and will lead to countless WTF moments.

Just my immediate thoughts on seeing the examples.

Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

I agree, $price = new MoneyValue(29.99); makes more sense and that's what I questioned in my first email.
The benefit is small, I said that as well, and the drawbacks are maybe bigger as you already outlined.

-----Ursprüngliche Nachricht-----
Von: Johannes Schlüter [mailto:johannes@schlueters.de]
Gesendet: Mittwoch, 26. Juni 2013 14:14
An: Robert Stoll
Cc: RQuadling@GMail.com; 'Tom Oram'; 'PHP internals'
Betreff: Re: AW: [PHP-DEV] RFC Proposal: New assign value operator

As far as I see it, it is kind of an operator overload mechanism for the assign operator.
This can be useful for small utility classes such as Money, Email etc.

An example was given:
$price = new MoneyValue();
$price := 29.99;

Instead of writing something like:
$price = new MoneyValue();
$price->setPrice(29.99);

The benefit is small, but can lead to better readable code. But since
it is only for the assign operator and not for + - etc., for me the
question remains open why not writing something like this directly:

$price = new MoneyValue(29.99);

I see no benefit.

It adds a new operator with new semantics which one has to learn to understand the code and which is hard to Google.

Also such objects seem to be value objects, so it should be immutable thus allowing code like

$price = new MoneyValue();
$price->setPrice(29.99);

looks like bad design.

If you have to type

$price = new MoneyValue(29.99);

often you can shorten it

use MoneyValue as MV;
$price = new MV(29.99);

sure still longer than := but no new syntax and more explicit.

johannes

2013/6/26 Robert Stoll rstoll@tutteli.ch

As far as I see it, it is kind of an operator overload mechanism for the
assign operator.
This can be useful for small utility classes such as Money, Email etc.

An example was given:
$price = new MoneyValue();
$price := 29.99;

Instead of writing something like:
$price = new MoneyValue();
$price->setPrice(29.99);

The benefit is small, but can lead to better readable code. But since it
is only for the assign operator and not for + - etc., for me the question
remains open why not writing something like this directly:

$price = new MoneyValue(29.99);

You forgot the currency ;) (without it a "money"-type is useless). But this
leads to

$price := 29.99;
$price := 'USD';

I find it confusing.

Not to mention, that one should NEVER use float for money
http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

Well indeed, that would be very confusing and is not really what I meant.
But it was an example anyway and don’t blame me when it does not fit in your
use case ;-)

No seriously, you can take email as an example instead:

$email = new Email();

$email := ‘rstoll@tutteli.ch’

Instead of writing

$email = new Email();

$email->setEmail(‘rstoll@tutteli.ch’);

But again, $email = new Email(‘rstoll@tutteli.ch’); would probably make
more sense.

For primitive types, we could see := as a shortcut for $a = (cast) $b; For
instance,

$a = 1; //$a is an integer

$a := “2”; //instead of $a = (int) “2”;

But IMO this does not really add some benefit either since PHP is weak typed

Cheers

Von: Sebastian Krebs [mailto:krebs.seb@gmail.com]
Gesendet: Mittwoch, 26. Juni 2013 15:30
An: Robert Stoll
Cc: Richard Quadling; Tom Oram; PHP internals
Betreff: Re: [PHP-DEV] RFC Proposal: New assign value operator

2013/6/26 Robert Stoll rstoll@tutteli.ch

As far as I see it, it is kind of an operator overload mechanism for the
assign operator.
This can be useful for small utility classes such as Money, Email etc.

An example was given:

$price = new MoneyValue();
$price := 29.99;

Instead of writing something like:
$price = new MoneyValue();
$price->setPrice(29.99);

The benefit is small, but can lead to better readable code. But since it is
only for the assign operator and not for + - etc., for me the question
remains open why not writing something like this directly:

$price = new MoneyValue(29.99);

You forgot the currency ;) (without it a "money"-type is useless). But this
leads to

$price := 29.99;

$price := 'USD';

I find it confusing.

-----Ursprüngliche Nachricht-----
Von: Richard Quadling [mailto:rquadling@gmail.com]
Gesendet: Mittwoch, 26. Juni 2013 12:51
An: Tom Oram
Cc: PHP internals
Betreff: Re: [PHP-DEV] RFC Proposal: New assign value operator

Hi everyone,

I've got an idea for an RFC proposal and from reading the instructions
it looks like I should run it past you guys first.

I have not made any contributions to PHP before although I have made
some custom modifications in house in the past and while I'm no longer
familiar with the PHP code base I am confident I have the skills to
implement this should it be accepted.

What I want to propose is a new assignment operator which rather than
setting the variable to completely new value it would update the value
while maintaining the type.

The main motivation for this is for easy assignment to value objects
aka assignment operator overloading via a magic method (prehaps called
__assign).

Here is an example ( for now I will use the PASCAL style assignment
operator := as the new operator as it is a know assignment operator
and currently not used in PHP):

// For a class defined like so...
class MoneyValue
{
protected $amount;

public function __assign($value)
{
    $this->amount = $value;
}

}

// The amount could then be assigned using the new operator like this

$price = new MoneyValue();

$price := 29.99;

While the primary focus would be for assignment operator overloading
as I just displayed in the previous example, for consistency it could
be used with scalar values to preserve type like so:

// $str is now a string

$str = 'Original String';

// Using the new assignment variable would cast the value being
assigned to the variable's type // (in this case a string). So

$str := 7;

// Would be the equivalent to
//
// $str = (string) 7;
//
// $str === "7"

Another quick example:

$num = 5;

$num := '12';

// Equivalent to
//
// $num = (int) '12';
//
// $num === 12;

So what do you guys think?

If I get a good response I'll look into how to create a proper RFC and
start trying to work out how to implement it.

Many thanks and look forward to some responses, Tom

Hi.

I'm not going to comment on the merits as such, but I'd be interested in
knowing what problem this RFC would solve?

Considering PHP has type juggling scalars, it would SEEM (I may have missed
the point) that this could result in data loss when the enforced conversion
results in 0/False/"".

$num = 8;
$num := "data from user"; // 0

Unless that is the expected behaviour.

Where would this RFC change be used?

And having said all of that, I'm not against it, just want to see what it
would be useful for that isn't already part of PHP's toolbox.

--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

--

--
github.com/KingCrunch <https://github.com/KingCrunch

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

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

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/

--

--

---

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

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.