@Stephen Reay <[email protected]>
> In languages without type hinting (e.g. JavaScript) - the “boiler plate”
you’re trying to remove is also common, e.g. using `typeof` in JavaScript.
It's also very common to *not* check types in JavaScript... I assume the
absence of type hints is partly responsible for this, and a reason why
quite a lot of JS developers turn to typed preprocessors, such as
TypeScript.
> Assigning a variable to itself, because you want to check its type is the
weirdest concept I’ve heard in a long time.
I assume you're speaking of the foreach() example; sure, used this way, it
looks like a self-assignment, but in most cases it's not, it's an inline,
checked type-hint:
// (assuming the 'as' syntax, now that the cast syntax has been buried)
$foo = $entityManager->find(User::class, 123) as User;
You're effectively adding, **inline and with just a few chars**, an
additional type-hint and runtime check to the value. I wouldn't call this a
no-op.
> You want to add more capability to enforce type checking - I get that,
and I share that goal. But when we already have pretty common, intuitive
syntax to do so in one situation, I don’t see why you wouldn’t adopt the
same syntax elsewhere.
While I don't agree with you on many points, I appreciate that we share the
same goal somehow, and hope that we can find common grounds. I would
personally not be against variables typed on declaration, but even though
this probably does not make sense, I'm somehow more comfortable with:
function test(string $name) {
$name = 123;
}
than:
string $name = 'Ben';
$name = 123;
I guess that I could be more comfortable with this approach if we had a
switch, such as `declare(locked_types=1)`, that would enforce the type of
the variable throughout its lifetime. This may come at a huge runtime cost,
though.
- Ben
