> On 23 Apr 2019, at 16:03, Benjamin Morel <benjamin.mo...@gmail.com> wrote:
>
> > I like the idea but I find the syntax (both suggestions) less than great,
> > given that there’s already “ensure a type” syntax, and both suggestions are
> > already used for other things (casting and foreach)
>
> Note that we already use `as` in other contexts than foreach: in imports
> (`use Foo as Bar`) and in traits (`use SomeTrait { foo as bar; }`) , so I
> think that reusing the keyword for yet another use case is OK, as long as it
> does not conflict.
>
> > Is there some reason (eg ambiguities) a type can’t just be placed before a
> > variable to ensure a type, similar to a function parameter or typed
> > property?
> > string $foo = 'bar';
> > ...
> > I’m talking about exactly the same functionality that exists with method
> > parameters - constraining the type it must conform to when it is declared.
> > Nothing more nothing less.
>
> I would personnally read this as "this variable is now strongly typed,
> INCLUDING later assignments" (which would belong to another feature /
> discussion), but as you have later clarified that this is not what you had in
> mind, I think that this syntax is then even more confusing than the other
> proposals:
>
> Foo $foo = new Foo();
> $foo = 123; // this would work?
>
> > Using `as` means trying to add type constraints to an iterable in the
> > foreach would be ridiculously confusing:
> > foreach ( $foo as $K as int => $v as string) {...}
>
> Please note that my proposal is specific to class/interface names, not other
> types for now (I could consider broadening it if people are interested in the
> suggested "as" syntax from Hack).
> Anyway with the two syntaxes suggested so far, you would not inline it in the
> foreach, but explicitly write:
>
> foreach ($foos as $foo) {
> $foo = (Foo) $foo;
> // or
> $foo = $foo as Foo;
> }
>
>
Hi Ben,
My objection to `as` is that it specifically prevents (or makes very confusing)
the `foreach` use I mentioned. There’s no variables involved in imports/traits,
and neither of those relates to foreach.
As for the `string $foo = $bar->getFoo();` ‘looking strongly typed’ and
wondering if it will allow re-declaration - do you think the same when you see
`function (string $foo) { $foo = explode(‘ ‘, $foo); }` ? Functions have
allowed type hints since 5.0 - nearly 15 years ago, and nobody seems to be
confused if those variables can be redeclared. Whether you *should* redeclare
them to a different value is something you need to decide for yourself.
As for limiting this to class/interface names - why would you do that? It took
YEARS to get scalar type hints for function parameters, why would you not
include them from the start on anything new that pertains to essentially the
same functionality?
I can’t even begin to comprehend how re-assigning a variable to itself (even if
it is a no-op internally, it *appears* to re-assign) to do a type check seems
like a good option.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
