Something else to consider: Right now, Constructors are checked on interfaces. See the following two examples:
http://codepad.viper-7.com/9IAGNP http://codepad.viper-7.com/edokLi So right now, interfaces are enforcing constructors fully (in 5.3). Which makes more sense: Having abstract methods behaving the same as the interface declaration (to grand-children, etc), or having abstract declarations behave differently and ignoring abstract constructors? My vote is for consistency (since the concept between abstract methods and interface methods is very similar)... Anthony On Thu, Nov 24, 2011 at 5:48 AM, Richard Quadling <rquadl...@gmail.com> wrote: > On 23 November 2011 18:37, Anthony Ferrara <ircmax...@gmail.com> wrote: >> Ralph: >> >> From where I'm sitting, I can see a few sane alternatives (there may >> be more, but here are the options I can see): >> >> Option 1. Remove signature checking from constructors all together. >> (I don't care for this, but whatever). Additionally, since it's not >> enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised >> on definition, as it is superfluous... >> >> Option 2. Fix grandchild signature checking to be inline for how >> signatures work with other methods. >> >> Personally, I think option 2 is the better one. I see it being odd >> and inconsistent that all methods work one way, and constructors work >> differently. But that's just my feeling (and I know others disagree >> there). >> >> And please don't reduce the error level of a signature change (as it >> would introduce even more inconsistency)... >> >> Just my $0.02... >> >> Anthony >> >> On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler >> <ra...@ralphschindler.com> wrote: >>> Internals: >>> >>> Time to summarize. >>> >>> It is clear to me that internals is divided on this issue. I don't think >>> it's a large enough issue to drag on, even when I disagree with it - both >>> theoretically and in practice. >>> >>> For most OO developer, putting ctors as an abstract or in an interface would >>> not happen anyway, so this does not affect them. >>> >>> ** The current change represents a minor break in BC, that should be noted >>> in the manual. ** >>> >>> Also, a decision needs to be made on what to do with grandchildren. As I >>> mentioned, the following produces no E_FATAL and no warnings: >>> >>> abstract class A { abstract public function __construct($a, $b); } >>> class B extends A { public function __construct($a, $b) {} } >>> class C extends B { public function __construct(ArrayObject $d) {} >>> >>> While this is correct behavior to me (ability for concrete to use its own >>> ctor), using the *current logic* strict signature checking enforced from an >>> abstract, then the above is also wrong. >>> >>> ** Can we decide what to do with that situation? ** >>> >>> On 11/18/11 5:05 AM, Pierre Joye wrote: >>>> >>>> I strongly disagree, this encourages bad practices. We could however >>>> reduce the error level to warning. >>> >>> I think this is a sufficient compromise- I don't see anything E_FATAL about >>> a signature change in ctors (I actually see nothing wrong with it, but it's >>> clear the community is divided there). >>> >>> ** Can we make that change? ** >>> >>> >>> Thanks, >>> -ralph > > What is the normal way for userland developers to learn about > constructors? Do they know about LSP? If they do, does it apply to > constructors? > > A comment on StackOverflow [1] > > "At its heart LSP is about interfaces and contracts as well as how to > decided when to extend a class vs. use another strategy such as > composition to achieve your goal." > > I am self taught. It was always my understanding that the constructor > was special in that it is, essentially, a magic method that can only > respond to the new keyword. Being able to call the constructor > directly, ..., that does feel a little odd as I can't actually > construct a new instance that way. > Using an interface to enforce the sig is fine. That's the exact nature > of an interface, to enforce the contract by design and if the > StackOverflow comment is accurate, then my understanding of interfaces > is fine with regard to LSP. > > An abstract class, by its very nature is not formed. It isn't a > contract. It is an idea and the concrete doesn't need to fit > perfectly. OK. There is some things that are fixed, method signatures > most accept the parameters defined in the subclass but can add more > (as I understand things). > > But is the signature of the constructor in an abstract class to be > enforced? I feel that it shouldn't be. It is a special method. > > WikiPedia [2] has an article on Constructor Overloading. It says > "Constructors, used to create instances of an object, may also be > overloaded in some object oriented programming languages.". OK, so > WikiPedia may have a different opinion tomorrow. > > Whilst we don't support overloading in the same way (I think we can > simulate it with __call() easily enough with ReflectionParameter being > my friend here maybe). > > We, DO, provide the tools to allow overloading and non LSP coding > practises. Is it a great leap to also allow the same flexibility with > constructors? > > Regards, > > Richard Quadling. > > [1] > http://stackoverflow.com/questions/56860/what-is-the-liskov-substitution-principle > [2] > http://en.wikipedia.org/wiki/Constructor_overloading#Constructor_overloading > -- > Richard Quadling > Twitter : EE : Zend : PHPDoc : Fantasy Shopper > @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : > fan.sh/6/370 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
