Mike Schinkel wrote:
On Feb 21, 2020, at 6:17 PM, Larry Garfield
<la...@garfieldtech.com> wrote:
Separate visibility for internal and external access is a separate
matter. (Also potentially useful, but not part of the write-once
proposal at the moment.)
This just hit me, so I think I will mention it.
The culture on the list seems not to be one of collaboration on RFC to
find solutions to improve PHP but instead waiting for someone to stick
their neck out with an RFC and then see who can shoot the most holes
through it.
Hi Mike.
I'm a newcomer to this list, but many years ago, I was more active on the
Boost C++ libraries list, where they have something called "formal review"
and it's not for the faint of heart.
In order for a library to be accepted as a Boost library, it has to go through
a rather rigorous review, where everyone and anyone are allowed to poke at
it and try to "shoot holes through it". This is not in any way done to discourage
library writers to come up with proposals, rather the opposite: By subjecting
a proposal to such scrutiny, where - like you said - people may also propose
changes to deal with those issues, the proposals become that much stronger.
This is similar to how science works: When someone proposes a theory, they
way it's tested to check if it's any good is to essentially do "destructive
testing": Try to break it, usually done first by the originator of the theory,
and later by the scientific community.
Take the theory of general relativity: This is one of the most well-tested
theories we have, and it has passed every test thrown at it with flying colours.
This is the light in which I see the reviews/discussions on this list as
well: By trying to "test" proposals even in extreme ways, we learn if they
are any good or not, or if they have some fundamental weaknesses that we
need to address.
Better to find that out now, than after it has been accepted into the language.
I also think what is important is that these discussions happen in a professional
and respectful way, and if you do that, then I think there's no limit to
how much you may "tear a proposal apart", again, which ultimately leads to
a stronger proposal, or a revision or retraction, if we find there are some
serious issues that warrant a reconsideration.
Now to the subject matter:
I'm in favour of simple and straight rules, and I'm wondering if we might
try a little too much if we are to cater for both write-once properties and
lazy loading. To take how you might do it in C++, you'd make a regular class,
and then make a const instance of it:
const User user(...);
When the constructor runs, it sets all object properties, and upon completion,
they are immutable.
We don't yet have the possibility to declare const objects (although this
proposal mentions it as a future RFC: https://wiki.php.net/rfc/declare_vars),
but maybe we could consider going this route?
Using PHP syntax, we may write:
const $user = new User(...);
Following the construction, the object is considered const/read-only, and
you can't change its object properties. There's no need to declare each property
as "readonly".
What about lazy loading? Well, C++ has a solution for this, as well: If you
need to be able to change properties for a const object, you can mark them
"mutable".
I know, this doesn't address the issue of actually preventing them to be
changed after having been set once, but I thought I'd at least inspire people
to think about how these things are done in other languages.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
