On Thursday, September 20, 2018 6:50:45 AM CDT Rowan Collins wrote: > On Thu, 20 Sep 2018 at 11:58, Nikita Popov <nikita....@gmail.com> wrote: > > I do not consider it advisable to require a null initialization as a > > "first iteration" of the proposal. Regardless of what our intention might > > be, the effect of such a restriction will not be "I'm not going to type > > this property for now, because non-nullable types are not supported", it's > > going to be "I'll give this a nullable type even though it isn't, because > > that's better than no type at all." Use of nullable types where they are > > not necessary would be a disastrous outcome of this proposal. > > This, ultimately, is where we disagree. To me, the "non-nullable types" > this proposal provides are non-nullable in name only, and using them does > little more than adding a comment saying "I promise this won't be null". > Encouraging people to use them gives them a false guarantee, and allowing > them to do so prevents us adding a stricter version of the feature later. > > > To move this discussion forward in a productive direction, we need a > > concrete, detailed proposal of how enforcement of initialization should > > work, while being compatible with secondary requirements. > > It feels to me that many of the "secondary requirements" are actually > separate problems which should be seen as pre-requisites, rather than > constraints. The lazy initialization pattern seems to be a hack around lack > of better support for property accessors. The mention of serializers > needing custom methods of initialisation reminded me of the occasional > discussion of better replacements for Serializable and JsonSerializable. > And so on. > > Fixing that list of pre-requisites would obviously take time, which is why > I wanted to buy that time by releasing initialised-only type hints first, > and working towards a greater goal. > > However, I've probably beaten this drum long enough. I will hope to be > wrong, and that making things stricter will still be possible later. > > Regards,
If I may...
I think the distinction here is that one group is arguing for "state of the
data assertions" while the RFC as implemented is "setter assertion shorthand".
That is, it doesn't assert that a value IS a given type, but that it can only
be SET TO a given type.
That naturally has some coverage holes. The question then being "is that
enough?"
I don't think a complete IS enforcement is possible given PHP's nature. We
don't enforce at compile time that you cannot call a function with an
incorrect type; that's enforced at runtime, or by a static analyzer. That is:
function test(int $a) {}
test($_GET['a']);
Cannot possibly be verified at compile time. This isn't a compile time check
either:
$b = 'foo';
test($b);
It's a runtime TypeError, not compile time.
That hasn't brought about the end of the world, so I'm not super worried about
imperfect property checks destroying everything.
That said, I totally appreciate the desire as a consumer of an object to know
that it's read-type-safe. I also get that there's many different pathways by
which an object could get initialized so there's no one clear validation
chokepoint.
But... could we have multiple?
To wit, could we add an engine check to scan an object and make sure its
objects are all type valid right-now (viz, nothing is unitialized), and then
call it on selected actions automatically and allow users to call it at
arbitrary times if they are doing more esoteric things?
I'm thinking:
* on __construct() exit.
* on __wakeup() exit.
* Possibly other similar checkpoints.
* When a user calls is_fully_initialized($obj); (or something)
is_fully_initialized() would return bool. The other checkpoints would throw a
TypeError.
That would layer on top of the current RFC cleanly, would give us the read-
assurance that we'd like in the 95% case, wouldn't require any new syntax
beyond a single function, and still lets serialization libraries do their
thing.
If needed, perhaps there's a way we can let a serialization tool disable that
check as an opt-out, and then the developer is just on-their-honor to get it
right. If it blows up later, well, file a bug with the serialization library.
In a dynamic runtime language I don't think we'll ever be able to do better
than that.
Would that be viable as a follow-up to the current RFC?
--Larry Garfield
signature.asc
Description: This is a digitally signed message part.
