Re: Object Type Casting Reloaded

> On 23 Apr 2019, at 21:54, Benjamin Morel <benjamin.morel@gmail.com> wrote: > > @Stephen Reay <php-lists@koalephant.com> > >> 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 Hi Ben, I realise type checking in JS is not really common, my intention was to indicate that the suggested $foo = $bar->foo() as Foo is basically unheard of in any language besides Hack. As has been suggested and refuted many times - less code is not necessarily more readable. In this case, I still feel $foo instanceof Foo || throwTypeError() or even a 3-liner if to do the throw inline, is more readable and more obvious than the proposed syntax. Yes - because of the syntax you’re proposing, this feature could never realistically be added to foreach statements without making them hard to read at best, and possibly (I don’t know, I’m not familiar with the C internals) impossible. Given that type hinting the members of an iterable is something that has been discussed and rejected before, the ability to hint types of an iterable is a no-brainer to me. It’s also one of the two examples Larry came up with. As I understand it, you find Foo $obj = $bar->getFoo(); to imply a fixed type for the variable $obj? I’ll just recap one more time, and then I’m not going to repeat this, because it’s surely getting boring for everyone else on the list. There is (as of 7.4) precedent for a typed “variable” that *is* locked to the type it’s declared with (class properties^), and for typed variables (function parameters) that are *not* locked to the type they're declared with. If this feature were added, it surely will follow the behaviour of one of those two: either they are or are not a fixed type, and one of the three cases will become the ‘exception’ developers need to remember when using typed variables/properties. ^: Yes I know class properties aren’t really the same as local variables, but they’re presented very similarly in syntax and behave mostly the same pre-7.4 I *assume* implementation wise it’s not even realistic to make local variables behave as 7.4+ typed class properties do (i.e. fixed type), but my point is that from a “do people want this” point of view, I believe the people who are actually likely to declare types on local variables, are *probably* quite unlikely to re-declare variables to a different type like that in most cases anyway. I’d also suggest that just adding local variable type hinting “now” (i.e. in 8.0 if an RFC passed) in a manner consistent with function parameter type hints, would mean that a later discussion/RFC could approach the concept of fixed-type variables (e.g using a declare option as you mentioned). Cheers Stephen