Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81510
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54CD7668.30301@garfieldtech.com>
Date: Sun, 1 Feb 2015 01:01:07 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <61B0AAF8-9A3E-4889-917E-42AA48D946FA@ajf.me>
References: <CAEbg-4YrBumSmCmvTbgVQTS=U2dm3gLzO6im69qQp6brxm=RMg@mail.gmail.com> <54CBC804.7050706@gmail.com> <54CD7668.30301@garfieldtech.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Immutable variables and objects
From: ajf@ajf.me (Andrea Faulds)

Hey Larry,

> On 1 Feb 2015, at 00:42, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Immutability, generally, offers two advantages:
>=20
> 1) It makes it easier for humans to reason about code.
>=20
> 2) It makes it easier for compilers/runtimes to reason about code.
>=20
> For the former, good programming practices/standards can often suffice =
as there are cases where immutability makes code uglier, not better.
>=20
> For the latter, it allows the compiler/runtime to do two things: Catch =
code errors early and optimize based on assumptions.

PHP doesn=E2=80=99t have immutable classes, though, so the PHP runtime =
*can=E2=80=99t* reason about code using value objects and such, and =
they=E2=80=99re less performant than mutable objects with manual =
copying.

I think having some means to create value type classes (i.e. PHP 4-style =
classes) would be beneficial. These classes would have the same =
always-copy or copy-on-write behaviour that PHP=E2=80=99s scalar types =
and arrays have. They=E2=80=99d be performant compared to immutable =
classes like PSR-7=E2=80=99s, because operations mutate the value =
in-place if possible, rather than creating a new class. They=E2=80=99d =
also be nicer to use, because you can change the value imperatively =
rather than having to chain together return values. But you keep the =
main advantages of immutable types: no spooky action at a distance, no =
explicit copying needed.

> What *could* be valuable, however, is flagging *parameters*.  Ie:
>=20
> function foo(const MyClass $c, const $s) {
>  $s =3D 'abc'; // Compiler error
>  $c =3D new MyClass(); // Compiler error.
>  $c->foo =3D 'abc'; // Some kind of error?
> }
>=20

const parameters are a cool feature in C. However, the main use for them =
in C doesn=E2=80=99t really exist in PHP. In C, most of the time you =
need to pass a pointer to a value to a function, rather than a value =
directly. Having a pointer to a value means you can modify that value. =
So, there=E2=80=99s a need for a =E2=80=9Cconst=E2=80=9D modifier to =
mark parameters as being for values that will be taken as input and not =
modified, rather than as values that will be used as output and =
modified.

PHP, on the other hand, doesn=E2=80=99t have pointers. Parameters are =
usually by-value (objects are by-reference, but still). If you want to =
mutate some value, you need to explicitly mark it as such=E2=80=A6 most =
parameters are already =E2=80=9Cconstant=E2=80=9D.

Though, I suppose there=E2=80=99s some usefulness in that, since all =
objects are by-reference, you might want to say you won=E2=80=99t touch =
that object. Hmm. Given that PHP is dynamic, not compiled, and function =
calls can have side effects, though, this would be difficult to enforce. =
You=E2=80=99d need to check that all calls made within the function do =
not have any side effects on that value=E2=80=A6

I=E2=80=99m not sure how workable this is.

Thanks.
--
Andrea Faulds
http://ajf.me/