Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108071
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CALKiJKqv_Q7vmPaOgzSzytZ5uH8jL7oFbbiLTNXpHTrh-mc-Bg@mail.gmail.com>
Date: Thu, 9 Jan 2020 15:28:10 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <106024FC-F36B-4E4E-9383-6430025A8D60@newclarity.net>
References: <5e0d723f.1c69fb81.e2ae8.24e2SMTPIN_ADDED_MISSING@mx.google.com>
 <74F2DBFC-E63C-428C-A37F-2D0CEE15AD0F@newclarity.net>
 <DM5PR07MB30676FC66DA036895D5E3554F9200@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CD014984-715D-49C5-9A90-66C0A11F9818@newclarity.net>
 <c40a96fe-8929-4b44-98bd-3370a12ec516@www.fastmail.com>
 <D56361F6-8B11-4363-908D-962F683936BF@newclarity.net>
 <b32edf0c-451d-2281-8036-0b631a3c7a6f@gmail.com>
 <CD3AFCD7-EF2F-46C7-90D3-3A83A1D8836C@newclarity.net>
 <53556dfb-44ce-f902-204c-9a7da9484a61@gmail.com>
 <65567C7C-CF0F-4562-8943-F1F302134B07@newclarity.net>
 <f9e2f739-4964-b259-d9e5-4aeec938c54b@gmail.com>
 <F48FF1DC-5DE9-4C30-8BCF-C17A1877AF37@newclarity.net>
 <6f20bda1-eff6-631d-915f-d6bb149ee666@gmail.com>
 <93BA4B49-9D9A-4A41-83B3-8EC2564A70BF@newclarity.net>
 <CALKiJKoi7AH0ypkQN8p7S8jeO2M1qNnyMUfdDM+w4iLwhskskg@mail.gmail.com>
 <A819AFCE-875E-432E-9D87-EC4D970DF1DD@newclarity.net>
 <CALKiJKqjXBr4jB7oh0gVPc9Q8ABgZaQ-=MzJb8Ry544Orr9oBA@mail.gmail.com>
 <CBAAE45D-E957-4033-B93C-5D7995C7209E@newclarity.net>
 <CALKiJKqv_Q7vmPaOgzSzytZ5uH8jL7oFbbiLTNXpHTrh-mc-Bg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)


> On Jan 9, 2020, at 4:38 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
> Sorry, I don't see it that way. To my mind, the universal use case =
here is
> "initialise some value once and then access it from the program"; the
> syntax is secondary to that.
>=20
> Evidently, you see those priorities differently; I don't think we're =
ever
> going to agree on that.

Your "disagreement" has the effect of either ignoring or dismissing the =
use-case that was the primary motivation for me to make this request.

If you want to dismiss my use-case at least please do so explicitly.

> What aspects am I dismissing? I absolutely agree that an equivalent to
> Java's final variables would implement your use case - if you were =
willing
> to relax your syntax constraint. But your proposal is not to have =
immutable
> variables, as you've said yourself.

You ask me to explore what other languages do. I explain that Java use =
`static final` to create constants which you can declare them =
dynamically.=20

You then claim that since constants are declared as final variables they =
are variables. Which is true, but they are also dynamically initialized =
constants. But then redirect to discussing PHP variables, which unlike =
Java have incompatible syntax to variables and thus cannot address my =
primary use-case.

Basically you asked me to give an example where constants are =
dynamically initialized, so I did, and then you claim those are just =
finalized variables. Which they are.  But they are also dynamically =
initialized constants.  Conceptually the difference is academic.

If I gave you an example of a compile time constant than it would be =
equivalent to PHP and unable to be initialized dynamically. If I gave =
you an example of a dynamically-initialized constant then yes, it is =
going to be a finalize variable. So effectively you set a trap for me =
that I could not satisfy, a catch-22.=20

Would you have accepted my example as evidence of other languages having =
dynamically-initialized constants instead if Java had used the `const` =
keyword instead of using `static final` keyword, but with identical =
implementation?  Or will you only accept compile time constants as an =
example, which by definition disallow initialization? =20

See the catch-22, and hence the distinction without a difference?

> See my my earlier comment about implementation - I'm not sure how we'd
> define valid values so that they definitely couldn't be mutable. You =
could
> restrict to just scalars, but that would then be a tighter restriction =
than
> actual constants - "const A =3D [1,2,3];" is valid right now,=20

Currently this does not work, so I do not see where the problem is:

class Foo {
   const BAR =3D [ 1,2,3 ];
}
Foo::BAR[0] =3D 9;  // PHP Fatal error:  Cannot use temporary expression =
in write context

> so preventing that being set dynamically would feel odd.

Did not propose that.

You can currently initialize const to an array now, and const arrays are =
currently immutable.  That would not need to change.

Further, we continue to disallow initializing const to objects, even =
dynamically. No change there.

So where is the issue?

> Perhaps I'm using the wrong terminology,

Probably, at least for me. For decades I have know "pre-processor" to =
mean textual substitution.  Maybe the newer hipster developers have =
redefined that term to mean something else, but I when I hear =
"pre-processor" I just think of pattern replacement in text.

(Note I am just being tongue-in-cheek about "hipster."  No real insult =
is intended. :-)

> but I think we're talking about the same thing: something that runs =
before the
> main program, which takes certain parts of the code, interprets them =
in some
> way, and combines them with the rest of the program.

In that context, I am open.

> So: an interpreter that runs during preloading, which takes special =
blocks of code,
> runs them as PHP, and then combines the results into the AST/OpCode
> representation of the program.

That actually sounds like the brilliant suggestion from Robert Hickman =
to consider the equivalent of compile-time code from the Jai programming =
language. If you have not watched these =E2=80=94 which I included again =
from Hickman's email =E2=80=94 I urge you to watch them as how Jai works =
with it's compile-time code execution really is brilliant:

- https://www.youtube.com/watch?v=3DUTqZNujQOlA. // Starting at 39:20
- https://www.youtube.com/watch?v=3D59lKAlb6cRg

> I stand by my comment that this has *some* of the same problems as a
> separate "build" script, such as the need to be configured correctly,

I find repeating of this as overstating the concern simply because any =
programming language feature would need to be used correctly.  So this =
also feels like a distinction without a difference.

> the difficulty of debugging errors in this special code,

Depends? If this where to use XDEBUG just like regular PHP there would =
be zero difference.

> and the need to invoke the extra processing manually for things like =
command-line scripts.

Since PHP is different from a pre-compiled language like C or Go, it =
compiles "on-demand." So I would see zero need for a build step.=20

I would also see PHP could first run the compile-time code once, and =
then run the runtime code for every execution. On-demand. And XDEBUG =
could be used for both.

For CLI, it might always run the runtime code and then the compile time =
code. Unless there is a standard location set of compiled opcode in .ini =
file, and/or unless PHP provided ways to generate OpCode artifacts to be =
loaded at runtime.

-Mike