On 07/01/2022 13:47, Robert Korulczyk wrote:
I'm not really sure why would you not want this - what is the point of
marking method as interface implementation, if it is not reflected by
type system in actual execution?
It's really quite simple: I don't want traits to tell me how I "must"
use
Hi Tim,
Thank you for opening the discussion. I personally find this feature
useful, and glancing at the diff, it looks like a rather
straightforward and minimal change.
FWIW, it is possible to selectively expose class properties in a class
object being `var_dump`-ed with the `__debugInfo` magic m
Hi Internals!
PHP's stack traces in exceptions are very useful for debugging, because
they include the original parameters for each stack frame, allowing the
developer to see exactly what data is passed to a function call.
Unfortunately sometimes this verbosity is a drawback. Specifically whe
I'm not convinced it does, actually. Consider the following trait:
trait PropertyCount {
public function count(): int {
return count(get_object_vars($this));
}
}
This trait CAN be used to implement the built-in Countable interface, and it might be useful to label it as such; b
> On 6 January 2022 07:29:58 GMT, James Titcumb wrote:
> >Just thinking out loud, being able to identify an array type might be a
> way
> >forward here (using "syntax" already in use by static analysis tools in
> >docblocks, for familiarity), e.g.
> >
> >private array $property;
> >
> >This might
Hi everyone. I've been lurking for a couple of days, but fwiw, I think this
RFC makes more sense as a built-in annotation.
Something like
#[partialImplemenation(Countable::class)]
trait PropertyCount {
public function count(): int {
return count(get_object_vars($this));
}
}
Ad
On 06/01/2022 23:53, Robert Korulczyk wrote:
But there is no easy way to say "`FooTrait::someMethod()` is
implementation of `FooInterface::someMethod()`" that PHP and SCA will
understand. And I think this proposal handles this quite well
I'm not convinced it does, actually. Consider the follo
