AW: PDM Meeting Notes

php.internals

Matthias Pigulla

20 years ago
> I don't see why you can't specify that a class definition must have a > constructor. Obviously the constructor is not for the > interface itself.
Ok, that is, having __construct in the interface asserts that everything you get passed (as an implementation of the interface) has been constructed by a constructor that has a certain signature? :--/ Of course it also doesn't make sense to call __construct on the implementation passed along. Luckily this is nothing I'm forced to write in my code ;). I only wanted to utter I have a Bad Feeling(TM) if you invest time and effort to make stuff like this work if the result is something that seems to make no sense [to me only?]. And once you allow it, be sure ppl out there use & abuse it and will complain should you ever have to remove it again. .. I'm just trying to make up a scenario where the above might make sense - it could be where you have something like a factory method. It has a type hint on it's argument to make sure what gets passed in implements a certain interface. That interface defines the signature of __construct, so the method can construct instances of the "thing" - only knowing that the instances constructed will implement the interface (?), but not knowing their implementation. But how should it construct instances? new INameOfTheInterface()? And besides that, problem is again that the "thing" passed in would have to be something representing a class, and not an instance of the class itself. You could always (gut feeling) re-design this to work "the usual way" by passing in something representing a class and providing behaviour to construct instances. I hope Andi backs me :) -mp.

Marcus Börger

20 years ago
Hello Matthias, Tuesday, November 22, 2005, 10:29:09 PM, you wrote:
>> I don't see why you can't specify that a class definition must have a >> constructor. Obviously the constructor is not for the >> interface itself.
> Ok, that is, having __construct in the interface asserts that everything > you get passed (as an implementation of the interface) has been > constructed by a constructor that has a certain signature? :--/ Of > course it also doesn't make sense to call __construct on the > implementation passed along.
> Luckily this is nothing I'm forced to write in my code ;).
> I only wanted to utter I have a Bad Feeling(TM) if you invest time and > effort to make stuff like this work if the result is something that > seems to make no sense [to me only?]. And once you allow it, be sure ppl > out there use & abuse it and will complain should you ever have to > remove it again.
The patch is ready already and actually it is a single line change that was obvious from the first place. What really causes work here is explaning this over and over again.
> I'm just trying to make up a scenario where the above might make sense - > it could be where you have something like a factory method. It has a > type hint on it's argument to make sure what gets passed in implements a > certain interface.
> That interface defines the signature of __construct, so the method can > construct instances of the "thing" - only knowing that the instances > constructed will implement the interface (?), but not knowing their > implementation.
> But how should it construct instances? new INameOfTheInterface()? And > besides that, problem is again that the "thing" passed in would have to > be something representing a class, and not an instance of the class > itself. You could always (gut feeling) re-design this to work "the usual > way" by passing in something representing a class and providing > behaviour to construct instances.
The typical way out is to completley re-design the software once reached this need or change to reflection to at least prevent from more severe errors. Best regards, Marcus