# __constructor parameter limitations. - Thread: https://externals.io/message/55475 - Original archive: https://news-web.php.net/php.internals/55475 - Started by Richard Quadling on 2011-09-17T13:27:33+00:00 - Messages: 83 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/55475.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #55475 — Richard Quadling — 2011-09-17T13:27:33+00:00 URL: https://externals.io/message/55475#55475 Hi. With the recent BC with regard the locking of the constructor's signature for subclasses, what is the expected mechanism for allowing a subclass to have additional parameters? You can always supply them and use `func_get_args()` / `func_num_args()` / etc. to read them. It would seem that the limitation restricts the capabilities. I'm not a purist. Software development is a compromise between purity and getting the job done in an efficient and understandable manner. By allowing undocumented parameters to the constructor (due to the enforced signature), this would seem to break things on a different front (I can't docblock non defined parameters for examples). Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea --- ## #55476 — Nikita Popov — 2011-09-17T13:43:26+00:00 URL: https://externals.io/message/55475#55476 · In reply to: #55475 Hi Richard! Which change are you talking about? I just tried doing: Hi. > > With the recent BC with regard the locking of the constructor's > signature for subclasses, what is the expected mechanism for allowing > a subclass to have additional parameters? > > You can always supply them and use `func_get_args()` / `func_num_args()` / > etc. to read them. > > It would seem that the limitation restricts the capabilities. I'm not > a purist. Software development is a compromise between purity and > getting the job done in an efficient and understandable manner. > > By allowing undocumented parameters to the constructor (due to the > enforced signature), this would seem to break things on a different > front (I can't docblock non defined parameters for examples). --- ## #55477 — devis@lucato.it — 2011-09-17T14:36:29+00:00 URL: https://externals.io/message/55475#55477 · In reply to: #55476 Hi, I think Richards intended other methods often used in combination with __construct: class A { public function init($a, $b) { } } class B extends A { public function init($a) { } } => PHP Strict Standards: Declaration of B::init() should be compatible with that of A::init() The example with __construct() is valid (at least in 5.3). Devis > Hi Richard! > > Which change are you talking about? I just tried doing: > class A { public function __construct($a) { } } > class B extends A { public function __construct($a, $b) { } } > And it worked on 5.4 Beta 1 without errors. > > Nikita > > On Sat, Sep 17, 2011 at 3:27 PM, Richard Quadling > wrote: > > […] --- ## #55478 — Ferenc Kovacs — 2011-09-17T14:52:53+00:00 URL: https://externals.io/message/55475#55478 · In reply to: #55476 maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ? but those change only affects the abstract classes. Tyrael > Hi Richard! > > Which change are you talking about? I just tried doing: >        class A           { public function __construct($a)     { } } >    class B extends A { public function __construct($a, $b) { } } > And it worked on 5.4 Beta 1 without errors. > > Nikita > > > > […] > > -- > > > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #55479 — Laruence — 2011-09-17T15:08:22+00:00 URL: https://externals.io/message/55475#55479 · In reply to: #55477 2011/9/17 : > Hi, > > I think Richards intended other methods often used in combination with > __construct: > > class A           { public function init($a, $b) { } } > class B extends A { public function init($a) { } } > > => PHP Strict Standards:  Declaration of B::init() should be compatible with > that of A::init() do you know any reason for this? > > The example with __construct() is valid (at least in 5.3). > > > Devis > > > > > > […] > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55480 — Laruence — 2011-09-17T15:15:20+00:00 URL: https://externals.io/message/55475#55480 · In reply to: #55478 Hi: this is really a big bc break...(fatal error) is there any reason for us to really change this? In Yaf, there are a lot of Abstract classes, the subclass only need declared there argument when they really need it. and I really not think this change is good one, the Intenal class can not be saw by userland(sure, doc, reflection), so they only get the FATAL ERROR(you are wrong) but will never be told how should they to do.. thanks 2011/9/17 Ferenc Kovacs : > maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ? > but those change only affects the abstract classes. > > Tyrael > > > > […] > > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > > -- > > > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55481 — Etienne Kneuss — 2011-09-17T15:17:29+00:00 URL: https://externals.io/message/55475#55481 · In reply to: #55479 > 2011/9/17 : > > […] > with > > […] > do you know any reason for this? > The reason for this is simply that B must act like A since every B object is also an object of A. > > […] > wrote: > > […] > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #55482 — Laruence — 2011-09-17T15:20:17+00:00 URL: https://externals.io/message/55475#55482 · In reply to: #55481 2011/9/17 Etienne Kneuss : > > > > > […] > > The reason for this is simply that B must act like A since every B object is > also an object of A. sure, but why we need interface? in addition, I don't think this can be done by restricting the argument thanks > > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55483 — Etienne Kneuss — 2011-09-17T15:21:18+00:00 URL: https://externals.io/message/55475#55483 · In reply to: #55480 > Hi: > this is really a big bc break...(fatal error) > is there any reason for us to really change this? In Yaf, there > are a lot of Abstract classes, the subclass only need declared there > argument when they really need it. > Well, that is wrong. if you declare an abstract method with a set of arguments, classes implementing that method should be compatible with that set of arguments. > > and I really not think this change is good one, the Intenal class > can not be saw by userland(sure, doc, reflection), so they only get > the FATAL ERROR(you are wrong) but will never be told how should they > to do.. Given that we have been quite flexible with this in the past, I don't believe a E_FATAL is warranted here, might be better suited as a E_STRICT, as there is no apparent reason why this would prevent the engine to continue. > thanks > > 2011/9/17 Ferenc Kovacs : > > […] > wrote: > > […] > wrote: > > […] > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #55484 — Laruence — 2011-09-17T15:54:11+00:00 URL: https://externals.io/message/55475#55484 · In reply to: #55483 2011/9/17 Etienne Kneuss : > > > > > […] > > Well, that is wrong. if you declare an abstract method with a set of > arguments, classes implementing that method should be compatible with that > set of arguments. > > > […] > > Given that we have been quite flexible with this in the past, I don't > believe a E_FATAL is warranted here, might be better suited as a E_STRICT, > as there is no apparent reason why this would prevent the engine to > continue. > Hmm, `E_STRICT` is better, I support. Thanks > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55485 — Ferenc Kovacs — 2011-09-17T18:00:13+00:00 URL: https://externals.io/message/55475#55485 · In reply to: #55481 > > […] > > The reason for this is simply that B must act like A since every B object is > also an object of A. > > The reason for restricting the method signature in the Subclass is to guarantee that an instance of a Subclass should work where an instance of the Superclass is expected. I think that this can be achieved with much weaker rules than expecting that the method in the Subclass has the exact signature as the Superclass. For example we do allow overriding visibility, but only weakening it(eg. private->protected or protected->public is allowed but public->protected isn't), else there could be cases where using the instance of the Superclass works, but the Subclass won't. Another thing that we should take into account: php is no java, so we don't have to require exactly matching method signature, as in php the method name cannot be ambiguous(we don't support declaring methods with the same name but different argument signature), and because of this passing more arguments than it was declared also supported in the userland functions/methods. So based on this, the following cases are which would make a Subclass incompatible with it's Superclass: - tightening visibility (we already restrict this) - declaring more arguments in the Subclass than in the Superclass, and having no default value for those. - declaring different typehints in the Subclass than it was declared in the Superclass. theoretically we could also allow changing the typehinting where it makes sense (for example it would be safe to allow changing the typehint from Foo to Bar if Bar extends/implements Foo), but I think that would require too much work, so I'm fine with requiring the same typehint if it was present in the parent. - removing default values from the arguments. (declaring the same argument as in the Superclass, but without default value, while the Superclass declared it with default value) the following cases would be allowed to change the method signature without making the Subclass incompatible with it's Superclass: - the Subclass could declare fewer arguments than it's Superclass. this could sound wrong, but as I mentioned, the engine allows passing more arguments, than it was declared, so Subclass would work everywhere where the Superclass is expected, and the arguments can be accessed through func_get_args. of course it would allow someone to shot himself in the foot(if he chose not to fetch the arguments from the method body), but that can happen already(for example. the Subclass can return different type than what the Superclass would, or it could throw different Exceptions, or just return some bogus value, etc.). - the Subclass could declare more argument than it's Superclass, as long, as the additional argument are having default values. - the Subclass could declare arguments without typehints which were declared with typehints in the Superclass. - the Subclass could declare arguments with default values which were declared without default values in the Superclass. for example: class super{ public function init(array $a=null){ } } could be extended like: // one additional argument, but it has default value, so it is fine class sub extends super{ public function init(array $a=null, $b=false){ } } // same argument but without the typehint class sub extends super{ public function init($a=null){ } } // fewer arguments class sub extends super{ public function init(){ } } // remove the typehint class sub extends super{ public function init($a=null){ } } but the followings are all invalid: // invalid, because it removes the default value class sub extends super{ public function init(array $a){ } } // invalid, because the additional argument doesn't have a default value class sub extends super{ public function init(array $a, $b){ } } // invalid, because changes the typehint class sub extends super{ public function init(StdClass $a, $b){ } } ps: the invalid signature should generate catchable fatal error, not fatal error imo, we are using fatal error many places where it would be reasonable to use Catchable fatal error, as Fatals should be only used where the Engine is left in an unstable state, or which cannot be recovered from. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #55486 — Stas Malyshev — 2011-09-17T18:08:47+00:00 URL: https://externals.io/message/55475#55486 · In reply to: #55481 Hi! > > > […] > > The reason for this is simply that B must act like A since every B object is > also an object of A. This is not a real reason, it's just repeating it. All B is saying in fact "I'm going to ignore everything but the first parameter", and there's no real reason not to allow it to do that. There's no "act" that makes B incompatible with A here, this warning is completely useless. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55487 — Reindl Harald — 2011-09-17T18:17:04+00:00 URL: https://externals.io/message/55475#55487 · In reply to: #55486 Am 17.09.2011 20:08, schrieb Stas Malyshev: > Hi! > > > […] > > This is not a real reason, it's just repeating it. All B is saying in fact "I'm going to ignore everything but the > first parameter", and there's no real reason not to allow it to do that. There's no "act" that makes B incompatible > with A here, this warning is completely useless in this case i agree practical sample: class a { public function whatever($param, $no_cache=0) { } } class b extends a { public function whatever($param) { } } think about $no_cache is a new param of a library class with a default value currently you have to "fix" all classes which are extend this class everywhere as long you are using `E_STRICT` which we are using on all production machines in combination with display_errors off and a global error-log for all hosts to make sure we are dealing with really clean code the same if b has an additonal parameter as long a has lesser params this is technical OK and compatible --- ## #55488 — Stas Malyshev — 2011-09-17T18:23:28+00:00 URL: https://externals.io/message/55475#55488 · In reply to: #55475 Hi! > With the recent BC with regard the locking of the constructor's > signature for subclasses, what is the expected mechanism for allowing > a subclass to have additional parameters? I think the whole "strict parameters" thing has gone into somewhat wrong direction and now we seem to have tons of useless errors and restrictions. For example, handling of bug #51421 seems to be wrong - there should be no problem if child method's signature is more permissive than the parent's. I do not see any point in it except puristic "enforcement" for the sake of enforcement, which doesn't seem to have any practical purpose. As for signature being more restrictive, in general case this should not be allowed as it is a LSP violation. The case can be made that ctor is not actually called on a real object but instead are used directly and statically, so more restrictive ctors are OK, but this is not true in the case of factories - i.e., if you do something like this: abstract class Base { function __construct($foo, $bar) { /* blah */ } function createBase($concrete, $foo, $bar) { if(!is_a($concrete, __CLASS__)) { throw new Exception("$concrete is not my descendant, can not create!"); } return new $concrete($foo, $bar); } This would fail if some concrete descendant of Base has additional restrictions on its ctor. So in this case the prohibition of additional restrictions is appropriate as well. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55490 — Etienne Kneuss — 2011-09-17T20:28:06+00:00 URL: https://externals.io/message/55475#55490 · In reply to: #55486 > Hi! > > > > […] > > This is not a real reason, it's just repeating it. All B is saying in fact > "I'm going to ignore everything but the first parameter", and there's no > real reason not to allow it to do that. There's no "act" that makes B > incompatible with A here, this warning is completely useless. > Right, In this very specific case the error should not be outputted, the check could be refined to let that pass. Just it it may be refined to handle contravariant typehints correctly > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > -- Etienne Kneuss http://www.colder.ch --- ## #55492 — Richard Quadling — 2011-09-17T21:39:20+00:00 URL: https://externals.io/message/55475#55492 · In reply to: #55478 > maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ? > but those change only affects the abstract classes. > > Tyrael > > > > […] My question was due to the documentation commit http://news.php.net/php.doc.cvs/8818 and http://news.php.net/php.doc.cvs/8819. Not being an expert, so I don't know all the theory, but it would seem an abstract class defines the idea and the concrete class defines it more - I need a better grasp of words here. An interface is the absolute here. Sub classes (the super class being abstract or otherwise), should be able to define MORE parameters (with or without default values). Otherwise they aren't extending, but implementing - and for me that's the role of an interface. It is only interfaces that guarantee things because the interface IS the guarantee. A class isn't beholden to anything it inherits. You can override methods, completely obscuring the super class if you so want. A subclass can completely divorce itself from the superclass. But not with an interface. PHP has always been a very very flexible language. I feel that if a developer absolutely must enforce a method's signature, then an interface is going to do that 100% and is a relatively easy way to do things. Enforcing method signatures in subclasses (I don't know why abstract classes are treated differently) does sort of make the interface redundant. Unless there is a real issue with the internal engine, then the method signatures should be flexible. Unless an interface is used. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea --- ## #55493 — Nikita Popov — 2011-09-17T21:53:20+00:00 URL: https://externals.io/message/55475#55493 · In reply to: #55492 > My question was due to the documentation commit > http://news.php.net/php.doc.cvs/8818 and > http://news.php.net/php.doc.cvs/8819. Just to clarify (as I'm not sure you got that change right): PHP has enforced signatures for methods defined in abstract classes already before 5.4. ("Enforce" doesn't mean that it's equal. The inheriting class can for example define further optional arguments. Or change default values.) But constructors were excluded from this for some reason. As of 5.4 constructors are handled the same way as other methods. So, in 5.4 nothing fundamental was changed, only constructors were adjusted to be handled like any other function. In my eyes this makes sense. Abstract methods define method signatures, just like interfaces do. So they should be enforced as such. (The thing about the new `E_STRICT` warning with normal classes is a very different thing. That behavior doesn't make any sense to me.) Nikita --- ## #55494 — Stas Malyshev — 2011-09-17T21:55:34+00:00 URL: https://externals.io/message/55475#55494 · In reply to: #55492 Hi! > An interface is the absolute here. Sub classes (the super class being > abstract or otherwise), should be able to define MORE parameters (with > or without default values). Otherwise they aren't extending, but > implementing - and for me that's the role of an interface. No, this is not correct. Requiring more parameters, despite seeming like "extending", is actually not extension but additional restriction - if you had function with 1 param, you could call it as foo(1) or foo(1,2) (in the second case 2 would be ignored) but if you add second parameter now only foo(1,2) works. The new method is more restrictive than the old one, and that shouldn't happen in proper OO. > It is only interfaces that guarantee things because the interface IS > the guarantee. > > A class isn't beholden to anything it inherits. You can override > methods, completely obscuring the super class if you so want. This is a wrong thing to do and should be avoided at all costs. Or, putting it other way, if you want to do this, do not use inheritance, it's not for that. By using inheritance, you agree to a contract that says "this class is at least as good as the base class, but maybe also better". Violating this contract is setting yourself up for all kinds of trouble. > A subclass can completely divorce itself from the superclass. It "can", technically, but it should not. Of course, we can not control it, except for most basic cases, but at least in basic cases we can. Now, I have absolutely no idea where separate treatment of abstract and non-abstract classes came from - can anybody explain that (preferably people that actually implemented that)? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55495 — Pierre Joye — 2011-09-18T08:58:27+00:00 URL: https://externals.io/message/55475#55495 · In reply to: #55492 hi, My two cents: For one I do think that enforcing strictness, or as I see it, clean code and implementation, should be done in php. We did not do that in the past and it has created more issues than anything else in the long run. One solution to solve the need of having different methods or constructors signatures is to support multiple signature per method or constructor, as long as the signature of the parent class or interface is available. This is something becoming more and more common in other languages and is actually very handy. Having such things would have also avoided bad (per design while necessary) sutff like the recent reflection function to create objects without invoking the constructor. > A subclass can completely divorce itself from the superclass. > > But not with an interface. > > > PHP has always been a very very flexible language. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55496 — frederic.hardy@mageekbox.net — 2011-09-18T12:26:58+00:00 URL: https://externals.io/message/55475#55496 · In reply to: #55495 Hi ! > For one I do think that enforcing strictness, or as I see it, clean > code and implementation, should be done in php. We did not do that in > the past and it has created more issues than anything else in the long > run. +1. > One solution to solve the need of having different methods or > constructors signatures is to support multiple signature per method or > constructor, as long as the signature of the parent class or interface > is available. This is something becoming more and more common in other > languages and is actually very handy. Having such things would have > also avoided bad (per design while necessary) sutff like the recent > reflection function to create objects without invoking the > constructor. +1. The possibility to defined multiple signature per method will be a great improvement. A class like this : class foo { function barForArray(array $array) {...} function barForACall(aCall $objectClass) {...} function barForCallable(Callable $callable) {...} } foreach ($arrayOfUndeterminedThings as $data) { switch (true) { case is_array($data): $foo->barForArray($data); break; case $data instanceof aCall: $foo->barForACall($data); break; case $data instanceof Callable: $foo->barForCallable($data); break; } } will become : class foo { function bar(array $array) {...} function bar(aCall $objectClass) {...} function bar(Callable $callable) {...} } foreach ($arrayOfUndeterminedThings as $data) { $foo->bar($data); } Best regards, Fred -- ======================================================================== Frédéric Hardy : Architecte d'application/Admin. système/Ergonome CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf Blog : http://blog.mageekbox.net Twitter : http://twitter.com/mageekguy ======================================================================== --- ## #55497 — Laruence — 2011-09-18T14:58:39+00:00 URL: https://externals.io/message/55475#55497 · In reply to: #55496 Hi: if this change will not revert, I will ask a more clearly error message for this, I report a req, https://bugs.php.net/bug.php?id=55719, which is, the error message should told user what the correct argument list is. and also submitted a patch for this req. thanks 2011/9/18 Frédéric Hardy : > Hi ! > > > […] > > +1. > > > […] > > +1. > The possibility to defined multiple signature per method will be a great improvement. > > A class like this : > > class foo > { >        function barForArray(array $array) {...} >        function barForACall(aCall $objectClass) {...} >        function barForCallable(Callable $callable) {...} > } > > foreach ($arrayOfUndeterminedThings  as $data) > { >        switch (true) >        { >                case is_array($data): >                        $foo->barForArray($data); >                        break; > >                case $data instanceof aCall: >                        $foo->barForACall($data); >                        break; > >                case $data instanceof Callable: >                        $foo->barForCallable($data); >                        break; >        } > } > > will become : > > class foo > { >        function bar(array $array) {...} >        function bar(aCall $objectClass) {...} >        function bar(Callable $callable) {...} > } > > foreach ($arrayOfUndeterminedThings  as $data) > { >        $foo->bar($data); > } > > Best regards, > Fred > -- > ======================================================================== > Frédéric Hardy : Architecte d'application/Admin. système/Ergonome >                     CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf >                  Blog : http://blog.mageekbox.net >              Twitter : http://twitter.com/mageekguy > ======================================================================== > > > -- > > > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55498 — Derick Rethans — 2011-09-18T15:09:18+00:00 URL: https://externals.io/message/55475#55498 · In reply to: #55488 > > > […] > > I think the whole "strict parameters" thing has gone into somewhat wrong > direction and now we seem to have tons of useless errors and restrictions. If you don't want those warnings, turn them off! That's why there is a specific error level for it. Derick --- ## #55500 — Pierre Joye — 2011-09-18T15:17:28+00:00 URL: https://externals.io/message/55475#55500 · In reply to: #55498 > > > > […] > > If you don't want those warnings, turn them off! That's why there is a > specific error level for it. Well, that won't help for fatal error, which is what's this discussion is all about, or almost :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55501 — Stas Malyshev — 2011-09-18T18:01:51+00:00 URL: https://externals.io/message/55475#55501 · In reply to: #55498 Hi! > If you don't want those warnings, turn them off! That's why there is a > specific error level for it. 1. It's not possible to turn these specific warnings off. The error level turns off all warnings on the level, not just specific ones. 2. These warnings don't warn about anything useful. There's no problem there to warn about. 3. Some of them aren't actually a warnings but fatal errors. Example: abstract class BaseClass { abstract public function foo(Type1 $foo, Type2 $bar); } class ExtendedClass extends BaseClass { public function foo() { } } This doesn't make sense on two levels: there's no reason why I can't extend foo() this way and there's no reason why abstracts are treated differently from non-abstracts. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55502 — Nikita Popov — 2011-09-18T18:23:39+00:00 URL: https://externals.io/message/55475#55502 · In reply to: #55501 > 3. Some of them aren't actually a warnings but fatal errors. Example: > > abstract class BaseClass { >    abstract public function foo(Type1 $foo, Type2 $bar); > } > > class ExtendedClass extends BaseClass { >   public function foo() { >   } > } Just to make sure that we all got the situation right: The above code throws the very same error on 5.3, on 5.2 and probably every other PHP 5 version before that (http://codepad.viper-7.com/Mb9Syu, http://codepad.viper-7.com/lwmlaQ). 5.4 only made the behavior consistent for constructors. I didn't see any complaints about this "feature", so I don't really see a reason why we should break BC with 5.3 here and drop the error message. > This doesn't make sense on two levels: there's no reason why I can't extend > foo() this way and there's no reason why abstracts are treated differently > from non-abstracts. I already tried to explain why it makes sense: An abstract method is much like an interface. Both define signatures without implementation. If their signatures weren't enforces, what would abstract methods be good for? An abstract method (for me) is a way for an abstract class to tell you: I need this and that method accepting these and these arguments to work correctly. If the signature isn't enforced, this doesn't make sense anymore. You could just as well drop the signature from abstract method definitions, as it's pointless then. Nikita --- Next page: https://externals.io/message/55475.md?page=2