Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55535
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <CACQesk5pXFv-VfTwRCGvFb4oG-aqtLwmwjfQOttF=mMBfrE8QQ@mail.gmail.com>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
 <4E74E5A0.2030006@sugarcrm.com> <alpine.DEB.2.02.1109181708480.3630@whisky>
 <4E76320F.6010904@sugarcrm.com> <CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com>
 <4E764137.9080507@sugarcrm.com> <CAEZPtU6yBMP3X8_EpUXauDifAWEJwXS4fki5HtYNybWoCQ0kFw@mail.gmail.com>
 <4E7685DE.6010805@sugarcrm.com> <CAEZPtU6LvwM+qDCKQr+XOUu8Ab+QK2=hbkykD_d=jWiAwB8ozA@mail.gmail.com>
 <4E768C86.3030307@sugarcrm.com> <CAEZPtU4SONqYvAnj739-NdDYC=9DGkLrC=_cB-Ay6KJEbTpJZg@mail.gmail.com>
 <4E769418.6040200@sugarcrm.com> <4E76CD67.2020700@thelounge.net>
 <4E77080E.7030107@mageekbox.net> <CACQesk5pXFv-VfTwRCGvFb4oG-aqtLwmwjfQOttF=mMBfrE8QQ@mail.gmail.com>
Date: Mon, 19 Sep 2011 10:50:57 +0100
Message-ID: <CAKUjMCVSECu+wjjrrxU+7+-E5nOR0rBojvPp+xrqSN=4fdF4Kw@mail.gmail.com>
To: Etienne Kneuss <colder@php.net>
Cc: frederic.hardy@mageekbox.net, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: rquadling@gmail.com (Richard Quadling)

On 19 September 2011 10:17, Etienne Kneuss <colder@php.net> wrote:
> Hi,
>
> 2011/9/19 Fr=C3=A9d=C3=A9ric Hardy <frederic.hardy@mageekbox.net>
>
>> Hi !
>>
>> What is the utility of abstract method if implementation can not follow
>> the signature (constraints ?) of the abstract method ?
>>
> In this case, abstract methods are totaly useless !
>> Moreover, i think that it's not compatible with Liskov substitution
>> principle.
> Subclasses can loosen the preconditions, that's eactly what happens here =
and
> it is perfectly fine in theory.

WOW. I really didn't expect this as a response to what, for me, was
quite an innocent question. Normally I get a 3 comments pointing me in
the right direction and I'm happy.



Maybe its me. But something that is abstract certain implies to me a
loose idea. The keywords have inherent meaning. At least in English.


If a class, abstract or otherwise, has the requirement to have an
enforced parameter list for a method, then would seem to be the role
of an interface. An abstract class and an method declared in an
interface, both require implementation. But with an interface, you are
not able to change the parameters. would seem to satisfy LSP.

Unless you use an interface to enforce the parameter order, how else
do you guarantee the contract?

If you also enforce the parameters for other methods (abstract or
otherwise - I'm still not 100% on the reason for the difference - or,
at this stage, if there even is a difference), then interfaces are
seemingly redundant.

Take the following code ...

<?php
abstract class abstractBase {
  abstract public function __construct($a, $b);
}

class ConcreteBase extends abstractBase {
  public function __construct($a, $b, $c =3D null) {
  }
}

class SuperCrete extends ConcreteBase {
  public function __construct($a, $b, $c, $d =3D null) {
    parent::__construct($a, $b, $c);
  }
}

$cb =3D new ConcreteBase(1,2);
$sc =3D new SuperCrete(1,2,3);
?>


The signatures here feel completely right, though MAYBE one could
argue that SuperCrete's constructor is off because $c is not optional.

I don't think $a and $b can ever become optional or missing from any
sub-class' definition.


As things stand, 5.4.0-beta doesn't report any problem with this code.


Have I made a mountain out of a mole hill?
(http://en.wikipedia.org/wiki/Make_a_mountain_out_of_a_molehill for
those who don't know the English idiom).








--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea