Hi internals,
Based on the discussion of "Property accessor hooks, take 2" and the
set-hook argument type - I got to wonder why we still define "no type"
as mixed.
As the pseudo type mixed exists since PHP 8.0, which is already
out-of-date, I have the feeling it would be better to force people to
explicitly write mixed to widen the type of an overwritten function
and let "no type" inherit the argument and return type of the parent.
Example:
class A {
public function typed(int $var): int { return $var; }
public function untyped($var) { return $var; } // implicit mixed as
no overwrite
}
class B extends A {
public function typed($var) { return $var; } // implicit int as
inherited from overwritten function
}
class C extends A {
public function typed(mixed $var):mixed { return $var; } //
explicit mixed to widen the type
}
That do you think?
This is just something that come to mind without having the knowledge
nor time for this kind of RFC or implementation.
Greetings,
Marc
Am 09.03.2024 um 08:18 schrieb Marc marc@mabe.berlin:
As the pseudo type
mixedexists since PHP 8.0, which is already out-of-date, I have the feeling it would be better to force people to explicitly writemixedto widen the type of an overwritten function and let "no type" inherit the argument and return type of the parent.Example:
class A {
public function typed(int $var): int { return $var; }
public function untyped($var) { return $var; } // implicit mixed as no overwrite
}
class B extends A {
public function typed($var) { return $var; } // implicit int as inherited from overwritten function
}
This sounds like a bad idea to me as I cannot look at the function definition in class B and determine what the type of $var is.
On top of that: If the type of $var in A is changed then it would automatically also change in B. While this seems convenient it could also break B in subtle ways as the function suddenly gets different types than expected.
Regards,
- Chris
Am 09.03.2024 um 08:18 schrieb Marc marc@mabe.berlin:
As the pseudo type
mixedexists since PHP 8.0, which is already out-of-date, I have the feeling it would be better to force people to explicitly writemixedto widen the type of an overwritten function and let "no type" inherit the argument and return type of the parent.Example:
class A {
public function typed(int $var): int { return $var; }
public function untyped($var) { return $var; } // implicit mixed as no overwrite
}
class B extends A {
public function typed($var) { return $var; } // implicit int as inherited from overwritten function
}This sounds like a bad idea to me as I cannot look at the function definition in class B and determine what the type of $var is.
On top of that: If the type of $var in A is changed then it would automatically also change in B. While this seems convenient it could also break B in subtle ways as the function suddenly gets different types than expected.Regards,
- Chris
I guess my discussion with Larry was at least part of what you're referring to.
The proposal here would introduce the same problem as we discussed on the other RFC: inconsistency with what people are used to elsewhere in the language (eg untyped properties).
It also means that existing code would have the complete opposite effect to previously, making it a huge BC break. You'd likely have to have two stages: deprecate and then remove use of untyped parameters, and then reintroduce untyped to mean "inherited" type, which still suffers from the issues Christian pointed out.
I could get behind the "first half" of that process: making a type required (ie deprecating type-less parameters/properties) but I doubt there's enough support for that to pass a vote.
Cheers
Stephen