Hi! I followed the whole discussion, still it is not clear which one is considered good and which bad practice...
In ZF 1 and 2, ZendRegistry::__construct() has the following signature with 2 parameters: function __construct($array = array(), $flags = parent::ARRAY_AS_PROPS) while SPL ArrayObject (its parent) has this one with 3 parameters: ArrayObject::__construct() ([ mixed $input [, int $flags [, string $iterator_class]]] ) from https://github.com/zendframework/zf2/blob/master/library/Zend/Registry.phpand http://www.php.net/manual/en/arrayobject.construct.php There are other similar examples, e.g. ReflectionClass::getParentClass() and ZF Zend_Reflection_Class::getParentClass($reflectionClass = 'Zend_Reflection_Class') I don't know if being ArrayObject an SPL makes any difference, I hope not... Is the example relevant for the discussion ? I always found PHP flexibility one of its strong points, and since we don't have method overloading, limiting the signature extension or contraction doesn't sound very useful to developers. bye! Devis On 19 September 2011 16:53, Ferenc Kovacs <tyr...@gmail.com> wrote: > First of all, Anthony, thanks for joining into the discussion! > > >> With respect to the func_get_args argument, I see that as a non-issue. > >> Sure, you can do it. But if you do, you're lying about the > >> interface. You're telling the callers that you expect no arguments, > >> but then all of a sudden you error out. > > > > > > Well, we have no way of declaring that we accept an undefined number of > > arguments. So there is simply no choice here. > > maybe we should consider adding support for that, as I agree that it > would make the contract more clear. > > >> You're pushing all of the > >> interface declaration logic out of the interface and into code. > >> That's only going to create maintainability, readability and quality > >> issues as time goes on. Realistically, the only good use of > >> func_get_args is when you need to take in an unlimited number of > >> arguments. But if you do that, you should include the minimum number > >> in the API itself. So if you have a function add() that can take any > >> number of integers, the minimum that makes sense is 2. So you should > >> declare add($left, $right), and then use func_get_args to get all of > >> them to add together. However, with that said, I'd argue that it's > >> bad design to do that at all. I'd recommend instead taking an array > >> parameter and adding the elements of the array. Not only is it > >> cleaner and easier to understand, it also solves the problem of > >> extending that functionality (so you're not duplicating the > >> func_get_args in each child)... > >> > > > > By doing that, you also do exactly what you describe earlier, you push > the > > args checks in the code itself, as you could always pass an incomplete > > array, and you could error out earlier. > > > > Var-args functions have been quite used for many things, there is no > reason > > why we should flag that as bad practice now... is there? > > > > not that I know of, except that we have no explicit way to declare > signature. > > to reflect to the original points by Anthony: > bringing up the Square - Rectangle example was a bad one, but to quote > from the wikipedia entry: "Violations of LSP, like this one, may or > may not be a problem in practice, depending on the postconditions or > invariants that are actually expected by the code that uses classes > violating LSP. Mutability is a key issue here. If Square and Rectangle > had only getter methods (i.e. they were immutable objects), then no > violation of LSP could occur." > So while it can cause violation, it isn't a violation by itself. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
