On Sunday, September 23, 2018 1:18:02 AM CDT Rasmus Schultz wrote: > > That is the entire point of the elephant analogy: that knowing what can > > get in doesn't necessarily mean knowing what is already inside - BUT, > knowing what can get in may still useful in itself. > > I understood that, and I disagree - just knowing what can get in is not > useful or interesting in itself. It's not even a new language feature - you > can already achieve the same with a simple setter. It's just new syntax. > > The only reason it's interesting to control what can get inside with type > hints, is to enable the language to do something new - something it > couldn't already do, which is to guarantee that the type enforces it's own > state specification. > > I understood the analogy, and I don't agree.
You previously listed this as an example of problematic code:
class Test {
public string $b;
}
$b = 'foo';
$test = new Test();
And I agree, that's problematic, just not as show-stopping as you seem to feel
it is. Which is why I suggested adding a post-constructor-validation-check,
in which case the above code would fail with a TypeError on the last line (new
Test()), since it reached the end of the constructor without fulfilling its
property validation requirements. Because that is, in the end, the best we
can do without radical changes to how the language works.
Basically, we have 3 options:
1) Object properties may not ever be type hinted except as nullable, which is
kinda useless.
2) Object properties may be type hinted but a sloppy class author may still
leave them undefined/null if they're careless, which is the RFC today. (How
much of a problem you think this is depends on how sloppy you expect class
authors to be.)
3) Object properties may be type hinted and the class author has until the end
of the constructor to make sure they're fulfilled, otherwise TypeError on the
spot (what I'm proposing).
If option 3 is insufficient, please explain why. You have yet to comment on
that, just say the current RFC is awful. If adding the extra checks is
insufficient, offer an alternative. I cannot think of one that doesn't
involve adopting Rust's type system. (Which would be kinda cool, but also
horribly impractical to do within the next decade.)
--Larry Garfield
signature.asc
Description: This is a digitally signed message part.
