On Wed, Jan 19, 2022 at 7:07 AM Chase Peeler wrote:
>
> This can still be handled with abstract methods
>
>
While it is technically possible (I also came up with architecture hacks),
it is... not a good solution.
It is technically possible for the __toString() method to increment one of
the prop
On Tue, Jan 18, 2022 at 3:55 PM Jordan LeDoux
wrote:
> On Tue, Jan 18, 2022 at 11:13 AM Rowan Tommins
> wrote:
>
> >
> > The difference with the "trait requires interface" proposal is that I
> > don't understand what advantage it gives the author of the trait. What
> > decisions can you make as
On Tue, Jan 18, 2022 at 1:07 PM Rowan Tommins
wrote:
>
> Fair enough, that's a reasonable use case, thank you. I could quibble
> and say that "self" or "static" would probably work in that particular
> example, but I suspect that would just lead to an unproductive spiral of
> example and counter-
On 18/01/2022 20:55, Jordan LeDoux wrote:
In this situation, the return value of the trait requires that $this
implements the NumberInterface, however there is no way for the trait
itself to enforce this.
Fair enough, that's a reasonable use case, thank you. I could quibble
and say that "sel
On Tue, Jan 18, 2022 at 11:13 AM Rowan Tommins
wrote:
>
> The difference with the "trait requires interface" proposal is that I
> don't understand what advantage it gives the author of the trait. What
> decisions can you make as a library developer because you've said "users
> of this trait must
On 17/01/2022 18:03, Mike Schinkel wrote:
"...I must implement an abstract method"
"...I must implement all the methods in an interface"
"...I must pass all arguments declared in a function"
"...I must pass arguments that are of the type that were type-hinted"
In all of the
> On Jan 7, 2022, at 1:56 PM, Rowan Tommins wrote:
>
> 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
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
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
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
In your use cases, are these traits generally *using* the interface methods, or
*implementing* them?
It is both. However "implementing" case is more problematic, since "using" can be quite reliably handled by adding `assert($this instanceof
LoggerInterface)` or type hints in trait methods -
On 6 January 2022 19:51:46 GMT, Robert Korulczyk wrote:
>You're talking about classes that use traits, but I'm talking about traits
>themselves. If I open a class in editor, there is a straightforward way to
>check if specific method is implementation of an interface - check interfaces
>impleme
Your other points make sense, but I don't think this one does - there are no
implicit interfaces in PHP*, so all any tool cares about is:
1) Does the class declaration say that it implements an interface?
2) Does it actually contain the methods needed to do so, through any
combination of direct
On 6 January 2022 18:03:04 GMT, Chase Peeler wrote:
>I think most people see the tools as black boxes to make THEIR lives
>easier. They aren't concerned about whether it's added complexity to the
>tool itself.
Just to be clear, my comments were a response to an earlier message that
explicitly t
On Thu, Jan 6, 2022 at 12:37 PM Alexandru Pătrănescu
wrote:
> On Thu, Jan 6, 2022 at 7:12 PM Rowan Tommins
> wrote:
>
> >
> > But some comments seem to be hinting at some *separate* advantage, to do
> > with "correct usage" of the trait, which I haven't grasped. It's possible
> > that the mentio
On 6 January 2022 17:36:41 GMT, "Alexandru Pătrănescu"
wrote:
>Yes, traits are a language construct that has in general more negative
>implications than positive so it's good to keep an eye on their usage.
>One of the okish usages is to define some implementation for an interface
>that classes ca
On Thu, Jan 6, 2022 at 7:12 PM Rowan Tommins
wrote:
>
> But some comments seem to be hinting at some *separate* advantage, to do
> with "correct usage" of the trait, which I haven't grasped. It's possible
> that the mention of static analysis relates to that in some way, and I'm
> just completely
On 6 January 2022 16:25:04 GMT, Chase Peeler wrote:
> I think the advantage would come within the trait. If I say the trait
>expects an interface with two methods, then the tool can act as if the
>interfaces methods exist in the trait even if they aren't explicitly
>defined. As others have pointed
On Thu, Jan 6, 2022 at 11:20 AM Rowan Tommins
wrote:
> On 6 January 2022 15:21:28 GMT, Robert Korulczyk
> wrote:
> > It should also make it easier for SCA tools to understand
> >the code since they no longer need to know the whole project to
> understand that method from trait is implementation
On 6 January 2022 15:21:28 GMT, Robert Korulczyk wrote:
> It should also make it easier for SCA tools to understand
>the code since they no longer need to know the whole project to understand
>that method from trait is implementation of method from interface (which is
>really tricky right now s
> For point 1, we already have that. It's called abstract methods in traits. This is a solved problem that requires no further resolution. At best
it would be a shorthand to copying a few methods from an interface into the trait and sticking "abstract" in front of them. I really don't see a ne
On Wed, Jan 5, 2022 at 6:05 PM Larry Garfield
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> > First, I'm someone that mainly uses traits to implement the functionality
> > defined in an interface. I think that's one of the best uses for them.
> > However, I'm personally not a
On Wed, Jan 5, 2022 at 11:05 PM Larry Garfield
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> For point 2, that's mainly useful as a way to signal to other developers
> "hey, this trait has all but one method of the LoggerInterface, that's how
> you'd use it", and to signal sta
On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
> First, I'm someone that mainly uses traits to implement the functionality
> defined in an interface. I think that's one of the best uses for them.
> However, I'm personally not a huge fan of overly restrictive things. For
> instance, while the
On Wed, Jan 5, 2022 at 2:17 PM David Gebler wrote:
> On Tue, Jan 4, 2022 at 10:35 PM Kirill Nesmeyanov wrote:
>
> > How relevant do you think this idea/proposal is? And what possible
> > problems or solutions will this entail in the future?
> >
>
> I'm not convinced there's a reasonable need for
On Tue, Jan 4, 2022 at 10:35 PM Kirill Nesmeyanov wrote:
> How relevant do you think this idea/proposal is? And what possible
> problems or solutions will this entail in the future?
>
I'm not convinced there's a reasonable need for it. The very nature of
finding yourself in a situation where you
On 04/01/2022 22:35, Kirill Nesmeyanov wrote:
Since «traits» are often an indicator of not very good code and many may not
use them quite correctly, for example, as helpers, I suggest adding support for
the `expects` keyword to indicate that the trait is part of the code
decomposition taking i
>Среда, 5 января 2022, 4:17 +03:00 от Larry Garfield :
>
>On Tue, Jan 4, 2022, at 4:35 PM, Kirill Nesmeyanov wrote:
>> Hello internals!
>>
>> Since «traits» are often an indicator of not very good code and many
>> may not use them quite correctly, for example, as helpers, I suggest
>> adding suppo
On Tue, Jan 4, 2022, at 4:35 PM, Kirill Nesmeyanov wrote:
> Hello internals!
>
> Since «traits» are often an indicator of not very good code and many
> may not use them quite correctly, for example, as helpers, I suggest
> adding support for the `expects` keyword to indicate that the trait is
>
On Jan 4, 2022, at 14:35, Kirill Nesmeyanov wrote:
> Since «traits» are often an indicator of not very good code and many may not
> use them quite correctly, for example, as helpers, I suggest adding support
> for the `expects` keyword to indicate that the trait is part of the code
> decomposit
On Wed, Jan 5, 2022 at 12:36 AM Kirill Nesmeyanov wrote:
> Since «traits» are often an indicator of not very good code and many may not
> use them quite correctly, for example, as helpers, I suggest adding support
> for the `expects` keyword to indicate that the trait is part of the code
> deco
Hello internals!
Since «traits» are often an indicator of not very good code and many may not
use them quite correctly, for example, as helpers, I suggest adding support for
the `expects` keyword to indicate that the trait is part of the code
decomposition taking into account ISP.
For example
33 matches
Mail list logo
