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 <[email protected]> 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(
> '[email protected]',
> new Email('[email protected]'),
> new AdvancedEmail('[email protected]'),
> );
>
> 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 <[email protected]> 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 [email protected] 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 [email protected] 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
****************************************************