Damn. I must have done that to a lot of emails. Gonna have to resend them all when I get home. Sorry folks for dupes.
On 2 December 2016 at 14:46, Andrey Andreev <n...@devilix.net> wrote: > Hi again, > > On Fri, Dec 2, 2016 at 4:19 PM, Alex Bowers <bowersb...@gmail.com> wrote: > >> I don't see how the interface is equivalent. >> >> The benefit of this, is that you can convert types passed into a method >> to the type you expect automagically, Castable wouldn't allow that, only a >> new magic method (or reflection and user land code possibly?) would allow >> this. >> > > A magic method is essentially an implicit interface ... > The interface itself does nothing. But when it is implemented, the engine > will know that the class constructor is public and accepts a single > parameter - thus, also knowing that it could try to do a new > ClassName($yourParameterHere) > > >> >> As for the limitation of only one parameter being accepted, what would >> the other possible parameters be? >> >> Since this is based entirely on the casted variable, there can only >> possibly be one variable there, the one passed into that position in the >> functions arguments. >> >> > What I meant is - you cannot cast to a class that requires more than one > dependency to be instantiated - that's the obvious limitation. > > >> Arguably, this feature would resolve some bugs in peoples code, because >> it can allow better enforcing of types. >> > > It enables magic behavior, that's the opposite of enforcement ... If you > want to enFORCE something, you force the developer to do something, you > don't auto-magically do the thing for them. > > P.S.: I suppose you've hit "Reply" instead of "Reply All"? I was the only > recepient of the message I'm quoting. > > Cheers, > Andrey. > >
