Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55555 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85783 invoked from network); 20 Sep 2011 02:37:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Sep 2011 02:37:23 -0000 Authentication-Results: pb1.pair.com header.from=tjerk.meesters@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tjerk.meesters@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: tjerk.meesters@gmail.com X-Host-Fingerprint: 74.125.82.170 mail-wy0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:55073] helo=mail-wy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BD/10-18936-06CF77E4 for ; Mon, 19 Sep 2011 22:37:21 -0400 Received: by wyg30 with SMTP id 30so61839wyg.29 for ; Mon, 19 Sep 2011 19:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k4Ds99DBxcmQDtMMNrkW5NW5XqqmdCYX6ld1ECUL38Q=; b=ddhfANGY5tMZTU6FAdNSk/UclaCSxX+tyLpC5P3s5BMyQkwbXi08Hx1N7gMjAKaWb2 ScjtYwG57eoR3llnPiWQi4YtiAO7GbCEas27JCBf+i+JB0PWSsD4twToK+2OBaa1sRvc Q9EDLWB+W2aqi16ji8ERe0IYLPA5DZbu1rP6g= MIME-Version: 1.0 Received: by 10.227.133.144 with SMTP id f16mr3506438wbt.97.1316486237188; Mon, 19 Sep 2011 19:37:17 -0700 (PDT) Received: by 10.227.183.136 with HTTP; Mon, 19 Sep 2011 19:37:17 -0700 (PDT) Received: by 10.227.183.136 with HTTP; Mon, 19 Sep 2011 19:37:17 -0700 (PDT) In-Reply-To: References: <4E74E5A0.2030006@sugarcrm.com> <4E76320F.6010904@sugarcrm.com> <4E764137.9080507@sugarcrm.com> <4E7685DE.6010805@sugarcrm.com> <4E768C86.3030307@sugarcrm.com> <4E769418.6040200@sugarcrm.com> <4E770163.2090001@sugarcrm.com> <4E770770.60809@sugarcrm.com> Date: Tue, 20 Sep 2011 10:37:17 +0800 Message-ID: To: devis@lucato.it Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=0016e65b5e4284f50804ad565694 Subject: Re: [PHP-DEV] __constructor parameter limitations. From: tjerk.meesters@gmail.com (Tjerk Meesters) --0016e65b5e4284f50804ad565694 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 20, 2011 2:10 AM, 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 =3D array(), $flags =3D parent::ARRAY_AS_PROP= S) > > 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.phpa= nd > 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 =3D > '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 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 numbe= r > > >> in the API itself. So if you have a function add() that can take an= y > > >> number of integers, the minimum that makes sense is 2. So you shoul= d > > >> 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 pus= h > > the > > > args checks in the code itself, as you could always pass an incomplet= e > > > 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=E1cs > > @Tyr43l - http://tyrael.hu > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > --0016e65b5e4284f50804ad565694--