Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101127
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.89 cause and error)
Reply-To: internals@lists.php.net
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.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>
Message-ID: <be298e03-50ab-0008-23ec-30ed1f2c0cc6@fleshgrinder.com>
Date: Sun, 12 Nov 2017 10:49:42 +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: <3b592a4b-c56d-fd16-f977-7c9898fabf57@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="3UxvJoWWvWxT4q115g3ksm1gEVCmckhfu"
Subject: Re: [PHP-DEV] Constants and Access Modifiers
From: php@fleshgrinder.com (Fleshgrinder)

--3UxvJoWWvWxT4q115g3ksm1gEVCmckhfu
Content-Type: multipart/mixed; boundary="oUpqNtkF3Qo0MlWlmRlF3wKtLdtJVcdjf";
 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
Message-ID: <be298e03-50ab-0008-23ec-30ed1f2c0cc6@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>
In-Reply-To: <3b592a4b-c56d-fd16-f977-7c9898fabf57@gmail.com>

--oUpqNtkF3Qo0MlWlmRlF3wKtLdtJVcdjf
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 11/11/2017 9:51 PM, Rowan Collins wrote:
> On 11/11/2017 18:39, Fleshgrinder wrote:
>> On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
>>
>>> =C2=A0From this link, it looks like const in Dart has pretty much not=
hing in
>>> common with const in PHP, besides name, so in the interest of avoidin=
g
>>> confusion, I would not discuss it in the same topic.
>>>
>> Yes, Dart has a different understanding of const, which is exactly why=
 I
>> posted it for you guys. In the hope that it helps to get more differen=
t
>> views on the topic. Currently you are too concentrated on how it is
>> implemented in PHP at this time, and argue that it is impossible to
>> diverge from that path. Which is simply not true, we only have to ensu=
re
>> backwards compatibility.
>=20
> I think the point is that adding "single-assignment variables" (which
> Dart calls "final") or "deeply immutable values" (which Dart calls
> "const") would be a completely different feature which could be added
> side-by-side with what we have now, under a different name. What PHP
> calls "const" (in the context of classes) is neither of those features.=

>=20

I know and I repeat, I posted the link just to show that const can be
more than the const we currently have, and to fuel the discussion. I
never said that we have to have the same implementation they have. ;)

On 11/11/2017 9:51 PM, Rowan Collins wrote:
> The debate seems to be whether you view class constants as more like
> static properties, or static methods. Given this:
>=20
> class A { public const Foo =3D 42; }
> echo A::Foo;
>=20
> Is it equivalent to this (using an imaginary "readonly" modifier)...
>=20
> class A { public static readonly $foo =3D 42; }
> echo A::$foo;
>=20
> ...or is it equivalent to this (particularly if you imagine an
> optimising compiler that caches / inlines the result)?
>=20
> class A { public static function foo(): int { return 42; } }
> echo A::foo();
>=20
>=20
> The difference is that a field is never "abstract" - it either has a
> value, or it is undefined; you can't add a contract to an interface
> saying "you must have this field" either. A method, on the other hand,
> is assumed to encapsulate something - it's a black box with a contract,=

> so defining the contract without any implementation makes sense. (Note
> that I've called $foo a "field" to distinguish it from a "property", as=

> C# does: a property with a contract like "$foo { public get; private
> set; }" could indeed be abstract.)
>=20
> The interesting thing about the above examples is that the static metho=
d
> with a fixed return *already works right now*, whereas the readonly
> field doesn't exist; so it makes some sense to say that "const FOO" is
> PHP's way of saying "static readonly $FOO", and have it subject to
> similar semantics.
>=20
> Regards,
>=20

Other languages allow you to have a contract on fields.

    class A { const FOO: int =3D 42; }
    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. 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!

    class A { abstract public const FOO: int; }
    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.

As I said, the idea is to have a constant value that is known at compile
time. This is the definition of const in PHP. The only thing I was
asking for is to split definition and initialization by reusing the
abstract keyword.

--=20
Richard "Fleshgrinder" Fussenegger


--oUpqNtkF3Qo0MlWlmRlF3wKtLdtJVcdjf--

--3UxvJoWWvWxT4q115g3ksm1gEVCmckhfu
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

iQIcBAEBCAAGBQJaCBk2AAoJEOKkKcqFPVVrdtYQAJvp/qkHPp/VwUBR6iUEgi+X
Zr1iJczypJkrblHEdST9r0ZbWMIf5n9g/mH82Uu6rVNnh3j7AJHBjsLj6pxoTeCh
3jG+YbHB7Fnd/Zq9IeJgM4RCHS1GgdoSRCIlEpGLswnS0Xp4TpunR0AizDxDP8SV
SiqDb8SpCMz7/5eGAI3dkEmKB5E4f0K5oURyv750Csq5wkpFdFvqMfGNvgHPJWk4
/22sdmvnh6m2XJFrpItTKDVq0inRAARuoA2/AvH614V5MYiP+OVNnp1UgEpTyRDc
dR/KrfCZmaUrDmTWleoC7AwBfO0rqAcAH1mghSCpn8BQ5HDbSAaaUTUZFMn1JVPh
65tqv8E4KjpZl+FHLdundhd+JjnPE5O22LsEeRXxhnGOW17FQvyuvNYueblnVuyj
3uVx980md7bv+Cwu+Te6yJGHHbbRB2vKr7bIC4mcbJG+Hl5OmuNLifASLL2a2MZF
K7JXF83TneRV17/4ZLPTxTcs5NFzutjVLgFaLaEdc2yXIduMDG/EXUDaPyk3ua+3
Z54M/IWOoS0s6AnQAtOXJiAHCT6sBwiTKwIP75JOiESxG60sfJE/l5ZEHM+5MwNc
ECx0pzA2Kk1NQt7+Cn9s4S2ZDGe48j7mkKrZXnFrqxZqmKBuuPA/FRFuthLYHymk
pchx823fvmKQwqExjIy7
=WEa4
-----END PGP SIGNATURE-----

--3UxvJoWWvWxT4q115g3ksm1gEVCmckhfu--