Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108019
Message-ID: <93BA4B49-9D9A-4A41-83B3-8EC2564A70BF@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7CE767DC-DC3E-49D9-ABE7-EC0DAE28F8B5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 6 Jan 2020 20:13:00 -0500
In-Reply-To: <6f20bda1-eff6-631d-915f-d6bb149ee666@gmail.com>
Cc: internals@lists.php.net
To: Rowan Tommins <rowan.collins@gmail.com>
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>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_7CE767DC-DC3E-49D9-ABE7-EC0DAE28F8B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jan 6, 2020, at 4:59 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:

> I'm still struggling to understand why you need multiple constants, =
all mutable based on some other dimension.
> If the ultimate goal is to know the name and branch of the *current* =
environment, how do the constants help?

At least two come to mind:

1. Guard clauses for code you only want to run in one environment and =
not another.
2. Common code that is used by different websites.


> We'll just have to agree to disagree here. I stand by the assertion =
that "compile-time constants" are a well-defined feature, whose =
restrictions are part of their definition and purpose.

> That method is not actually a feature of constants, its abusing the =
fact that everything is an object, so the *value* of a constant might =
still be a mutable object. It's an interesting "cheat", but it's not =
really a deliberate language feature.

The .replace is not a deliberate language feature?

> Unless I'm missing something, this isn't really related to anything =
we've been discussing, it just happens to use the keyword "const".

It is not exactly the same, but it is used to create immutable values =
stored in variables, aka constants. Hence why I included.

> Those links seem to say that Python doesn't have constants *at all*, =
but you can emulate them in various ways. As such, you can give them =
pretty much whatever behaviour you like, since you're defining the =
language feature from scratch.

Yes. IOW, Python did not feel there was a need for a compile-time =
constant.

> The biggest sticking point in my mind is your insistence that they =
share syntax with constants, rather than variables. This means they can =
only be used in static class or namespace context, not against an =
instance.

It's not an insistence per se, it is the use-case I am trying to =
address.

I can already use static variables, and the immutability is not that =
important to me.=20

It's the desire to be able to start as statically declared constants and =
evolve later to dynamically initialized.

As for immutable variables, I see those as very useful to, but I think =
their use-cases are orthogonal to the use-case I was trying to address.

> It also means *widening* the meaning of a construct, rather than =
*narrowing* it: the "final" keyword in Java doesn't let variables do =
anything new, it just restricts them; your proposed constant =
initialization would allow constants to act in new ways, including =
holding complex, mutable types.

But isn't that often the point of new features; to allow for doing =
things in new ways?

> That's likely to cause confusion for both humans

I often chuckle when I hear that something might cause confusion as an =
argument against adding to PHP because it makes me think of PHP =
generators, generator return expressions and Generator delegation!

I assert that if we can add generators (and in the future, generics!) =
then most anything we could add is going to be less confusing. :-)

> and tools written based on the current concept that a constant can =
always be computed at compile-time.

My assumption is that the tool would simply be updated to recognize =
which constants would be initialized at runtime.

> The difference is that a Java-style "final variable" can have a single =
value *per instance*,

I cannot think of anything conceptual that would keep us from having =
constants per instance, but I don't see a strong need for is so I did =
not propose it.

> I would be interested to hear more about why you think pre-processing =
doesn't suit your use case.

When I think of pre-processor, I think of textual substitution.  It is =
very difficult if not impossible to write textual pre-processing code =
that is both reusable _and_ composible with pre-processing code that =
someone else wrote. Thus if there are several header files in the wild, =
you typically can only use one of them.

I am still influenced by the words of Bertrand Meyer in the book where I =
first learned object oriented programming "Object Oriented Software =
construction" in his section on Composability:

> "A method satisfies Modular Composability if it favors the production =
of software elements which may then be freely combined with each other =
to produce new systems, possibly in an environment quite different from =
the one in which they were initially developed."

> "Counter-example: preprocessors. A popular way to extend the =
facilities of programming languages, and sometimes to correct some of =
their deficiencies, is to use =E2=80=9Cpreprocessors=E2=80=9D that =
accept an extended syntax as input and map it into the standard form of =
the language. Typical preprocessors for Fortran and C support graphical =
primitives, extended control structures or database operations. Usually, =
however, such extensions are not compatible; then you cannot combine two =
of the preprocessors, leading to such dilemmas as whether to use =
graphics or databases."

=46rom page 42: =
http://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented%=
20Software%20Construction.pdf =
<http://web.uettaxila.edu.pk/CMS/AUT2011/seSCbs/tutorial/Object%20Oriented=
%20Software%20Construction.pdf>=20

Finally, a long time ago in a far away galaxy I was a Clipper developer, =
and in version 5.0 they implemented a preprocessor to enable =
user-defined commands. Many of us including myself jumped on them and =
created some pretty horrific architectures, and then quickly found what =
a nightmare they are when trying to combine them.

-Mike


--Apple-Mail=_7CE767DC-DC3E-49D9-ABE7-EC0DAE28F8B5--