On Sep 20, 2011 2:10 AM, <de...@lucato.it> wrote: > > 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 >
That's exactly why I think constructors should be exempted from "strict" signature checking. When you pass objects as a function parameter, the signature should match even though you pass an instance of a child class. That has been well established in some of the previous messages. However, I don't think this should apply to constructors in the same way. They can be 'simplified' as the child class becomes more specific. > 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 > > > >
