Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error)
Reply-To: internals@lists.php.net
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net,
 lists@rhsoft.net
References: <93a05192-ed34-2164-50f9-2799899b32d1@fleshgrinder.com>
 <CAF+90c_ZL2BP+T+fs2VWOf3CJQbMPVmj9+Hf2x1WpiMwUa1FNw@mail.gmail.com>
 <4ee3d414-92e1-75c7-402f-16a37ed3016b@fleshgrinder.com>
 <3f093ce2-e00e-f210-6e35-de31eb2f4b07@gmail.com>
 <CANUQDCiohX_G0h9Qkg0LXRZ-46vjaz4cDr=ScmQd3M1Nf13LvQ@mail.gmail.com>
 <0061a0c9-328c-75cb-cf6f-8e444e9ea3c0@fleshgrinder.com>
 <d87a08c8-0b0e-a06c-2aba-e1e4178c7e66@gmail.com>
 <2f555141-96e0-3bab-c191-1216747644a5@fleshgrinder.com>
 <3b592a4b-c56d-fd16-f977-7c9898fabf57@gmail.com>
 <be298e03-50ab-0008-23ec-30ed1f2c0cc6@fleshgrinder.com>
 <a5094113-7e7c-97cd-af06-4ccdfe212b80@gmail.com>
Message-ID: <5f8725a1-2186-e1a7-8651-b9d1369f1470@fleshgrinder.com>
Date: Sun, 12 Nov 2017 20:44:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <a5094113-7e7c-97cd-af06-4ccdfe212b80@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="L3RRxvCikiMolt71C98CjRnRc1jPbmbj3"
Subject: Re: [PHP-DEV] Constants and Access Modifiers
From: php@fleshgrinder.com (Fleshgrinder)

--L3RRxvCikiMolt71C98CjRnRc1jPbmbj3
Content-Type: multipart/mixed; boundary="IPj8ULwD3cWuvKAx0H4ET6p5mG59DeE01";
 protected-headers="v1"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net,
 lists@rhsoft.net
Message-ID: <5f8725a1-2186-e1a7-8651-b9d1369f1470@fleshgrinder.com>
Subject: Re: [PHP-DEV] Constants and Access Modifiers
References: <93a05192-ed34-2164-50f9-2799899b32d1@fleshgrinder.com>
 <CAF+90c_ZL2BP+T+fs2VWOf3CJQbMPVmj9+Hf2x1WpiMwUa1FNw@mail.gmail.com>
 <4ee3d414-92e1-75c7-402f-16a37ed3016b@fleshgrinder.com>
 <3f093ce2-e00e-f210-6e35-de31eb2f4b07@gmail.com>
 <CANUQDCiohX_G0h9Qkg0LXRZ-46vjaz4cDr=ScmQd3M1Nf13LvQ@mail.gmail.com>
 <0061a0c9-328c-75cb-cf6f-8e444e9ea3c0@fleshgrinder.com>
 <d87a08c8-0b0e-a06c-2aba-e1e4178c7e66@gmail.com>
 <2f555141-96e0-3bab-c191-1216747644a5@fleshgrinder.com>
 <3b592a4b-c56d-fd16-f977-7c9898fabf57@gmail.com>
 <be298e03-50ab-0008-23ec-30ed1f2c0cc6@fleshgrinder.com>
 <a5094113-7e7c-97cd-af06-4ccdfe212b80@gmail.com>
In-Reply-To: <a5094113-7e7c-97cd-af06-4ccdfe212b80@gmail.com>

--IPj8ULwD3cWuvKAx0H4ET6p5mG59DeE01
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 11/12/2017 7:25 PM, Rowan Collins wrote:
> On 12/11/2017 09:49, Fleshgrinder wrote:
>> Other languages allow you to have a contract on fields.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 class A { const FOO: int =3D 42; }
>> =C2=A0=C2=A0=C2=A0=C2=A0 class A { final static $foo: int =3D 42; }
>>
>> These are basically the same, as you already said. However, I added a
>> contract to both of them.
>=20
> Yes, I wondered whether to mention type constraints; certainly the
> previous, stalled, proposal would have added them directly on what I wa=
s
> calling "fields". The more I think about it, though, the more I think a=

> separate notion of "properties" like C# would be a great way to add new=

> constraints in a clear way.
>=20
> Consider "int $foo { public get; private set; }" as defining the follow=
ing:
>=20
> - a field which like any other variable could theoretically have any
> value, but which will never be accessed except via the property definit=
ion
> - a getter method with the signature "function(): int"
> - a setter method with the signature "function(int $foo): void"
>=20
> It immediately makes sense why you can't assign by reference (the sette=
r
> method doesn't take a reference, only a value). It also makes sense to
> have this present in an interface (the implementing class is obliged to=

> have such a property, but may define explicit getter and setter methods=

> rather than defaults).
>=20
> You could then also have syntax for a property with a compile-time valu=
e
> and no setter, but I'm not sure whether this meets your requirements.
>=20

Having this functionality would be more than awesome. Especially because
it would allow upgrade paths for anemic code bases where all properties
are public.

On 11/12/2017 7:25 PM, Rowan Collins wrote:>> There is one thing that
differs for the const
>> and the field: a const value must be known at compile time, whereas a
>> field value does not. An important difference!
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 class A { abstract public const FOO: int; }
>> =C2=A0=C2=A0=C2=A0=C2=A0 class A { abstract public function foo(): int=
; }
>>
>> These also look basically the same. The return value of the method,
>> however, may also be determined at runtime (just like with fields) and=

>> on top of that might change with every invocation.
>=20
> What I'm not really clear on is *why* the value being known at
> compile-time is important to you. Is there some architectural decision
> you would make differently based on this guarantee? Are you expecting
> the language itself to have some optimisation or different behaviour
> based on that guarantee?
>=20

I expect certain optimizations, and as my fellow Austrian countryman
Harald already said, there is enough room for them.

I also expect the ability to perform calculations at compile time,
instead of at runtime. The values would stay the same forever with
proper caching.

    abstract class A {
        abstract const X;
        abstract const Y;
        final const Z =3D self::X + self::Y;
    }

    final class B extends A {
        const X =3D 1;
        const Y =3D 1;
    }

On 11/12/2017 7:25 PM, Rowan Collins wrote:
> Would the ability to mark a function as "pure" (always returning the
> same output for the same input) serve the same purpose, since a pure
> function with no arguments can be substituted for its return value at
> compile time?
>=20
> abstract class A { abstract static pure function getFoo(): int; }
> class B extends A { static pure function getFoo(): int { return 42; } }=

> class C extends A { static pure function getFoo(): int { return 999; } =
}
>=20
> Regards,
>=20

Pure functions in general would be an awesome thing in PHP, as they also
allow for many optimizations.

--=20
Richard "Fleshgrinder" Fussenegger


--IPj8ULwD3cWuvKAx0H4ET6p5mG59DeE01--

--L3RRxvCikiMolt71C98CjRnRc1jPbmbj3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaCKSGAAoJEOKkKcqFPVVrbpsQAJ8i9Q6QkNM1BGkpPswNjtvd
e9mlWGxRBBw3i5m5UV46EW3owKAB3q+xtmLI6SF9JctFq2lulkxQlAFcIE+fsKe/
oXRG6chvGp31zF0aRjzMeyqkKFD6CY1xsFwOvWIiaLjTUAFhtynvNeF6CaFT/JF4
Go6bQzaIpM6xubztxfI6s3mHfHDYPgyJ2nuZPnh4EkXoKYMPD0p6Gt/AC4JWXD3N
9b9GT7nvvxwmp0sqQ57s7//GXYkT2wO0vNMhPyrAsGElWDdYDL49JgcIoTEuN56v
3PPrnzuMWXmmd08SoszylbhwLOleYjpa1i/p31aOuUTEIQs/pFn6JVOrp2fIUvfV
aE52JYjQbBOcBvCUBGLo1Ogu4GT+AqfdGl9g8NWaeYVfd8HpW8fpX6Mv0QndCOxq
quiuvoih5RHvmGrUbhvlt/JiDBTt2Iczk6nmCIny1LTRXiCYY3USE1mbq3l+Xgb9
u80NHdKOQJW3RNZYrr/hZquvsFJLLkpuMuibdjRpIqYPMwdi+p4/jSmLWsigcl54
Xn4qp35u9PqOzXYyi04VZgl5AM5ROewSE/iTID7FAcMLYRStrWUFywVzLqHMOJ0K
vDy9is272I3xSvOu/zKQINnP2UVGa3TFtdJVNP8BbBtys5fV/r2PnNUs2Q2V7uJG
tvlrCKkGKqpTcZL+dbHq
=8GXi
-----END PGP SIGNATURE-----

--L3RRxvCikiMolt71C98CjRnRc1jPbmbj3--