Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Adam Harvey'" <aharvey@php.net>,
	"'Dan Ackroyd'" <danack@basereality.com>
Cc: "'Nikita Popov'" <nikita.ppv@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com> <CA+kxMuSm0x26j4L5tyn_b1HxPkTKNZx2sTSG7qLKHpgrQNu3MA@mail.gmail.com> <CADajX4Db3z8FMKJEs7Uy7dr9MKmo4uJJ1c3E_dntr9Di7bOb7g@mail.gmail.com> <CA+kxMuQKKpRvWVqkmaSXoTApnqdhHCnm+Px78Gwf2FzvswXniw@mail.gmail.com> <CADajX4Cwi07809+AF5G+qX38JYc4Y_GaNv=6-T6RhCF1G5isqA@mail.gmail.com> <005701ceac1a$9369ba70$ba3d2f50$@tutteli.ch>
In-Reply-To: <005701ceac1a$9369ba70$ba3d2f50$@tutteli.ch>
Date: Sun, 8 Sep 2013 00:49:01 +0200
Message-ID: <005801ceac1c$727b7b80$57727280$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIRCtTWl6J3njxJ6HEYny8b14HHdQHSzPeGAdoNKukDGYexEwGxrYk5AbLScU6Y5Mm3oA==
Content-Language: de-ch
Subject: RE: [PHP-DEV] [RFC] Named parameters
From: rstoll@tutteli.ch ("Robert Stoll")



> -----Original Message-----
> From: Robert Stoll [mailto:rstoll@tutteli.ch]
> Sent: Sunday, September 08, 2013 12:36 AM
> To: 'Adam Harvey'; 'Dan Ackroyd'
> Cc: 'Nikita Popov'; 'PHP internals'
> Subject: RE: [PHP-DEV] [RFC] Named parameters
>=20
> > -----Original Message-----
> > From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
> Behalf Of
> > Adam Harvey
> > Sent: Friday, September 06, 2013 10:11 PM
> > To: Dan Ackroyd
> > Cc: Nikita Popov; PHP internals
> > Subject: Re: [PHP-DEV] [RFC] Named parameters
> >
> > On 6 September 2013 13:01, Dan Ackroyd <danack@basereality.com>
> wrote:
> > >> I'd say the odds are that those sorts of users are going to be
> > >> writing
> > >
> > >> code that is required to be notice/strict clean anyway =E2=80=94 =
that's
> > >> certainly been true everywhere I've worked that's had a "modern"
> > >> codebase.
> > >
> > > Yes, so say you have a team that:
> > >
> > > * currently has a code base that is notice/strict clean
> > > * wants to move to PHP 5.x which has named parameters
> > > * have code which changes the param name in extends/implements
> > >
> > > Unless they rewrite their code, they wouldn't be able to upgrade
> > > next version of PHP without losing their strict/notice cleaness. =
So
> > > how would you suggest they upgrade to the version of PHP with =
named
> > parameters?
> >
> > At the risk of being glib, by cleaning up their parameter names. A
> > team that's testing a PHP upgrade is likely capable of that, and the
> > strict notices would give them the needed feedback in the early =
stages
> > of testing. That's hardly a rewrite.
> >
> > > Also I'm not sure that having which error level is used actually
> > > changes the behaviour of the language in a meaningful way. It only
> > > suppresses a particular warning message, which can be suppressed
> > > anyway with error_reporting(0).
> >
> > I don't really care which level actually gets used (it could be
> > anywhere from E_STRICT to E_WARNING from where I sit), but I don't
> > think the error reporting for a particular feature should ever be
> > controllable separately from PHP's global error reporting. These =
sorts
> > of warnings are there to promote better practice.
> >
> > Adam
> >
>=20
> Heya,
>=20
> I do not like the check at all and after writing a few lines for this =
email,
> deleting, writing again etc. I have to conclude, named parameters do =
not
> really suit to PHP if such a check is really implemented. -1 in this =
case
>=20
> I understand that you have to make this check with your current =
solution. I
> did not have a look at the implementation though, but I guess this
> consistency of parameter names is needed since you do not know what =
type
> a variable has. This check of the whole class hierarchy certainly =
slows down
> also use cases where named parameters aren't used at all. But that's =
not
> even my biggest concern.
>=20
> Following an example to outline why I do not like the check:
>=20
> interface IExecutor{
>     function execute(callable $command); }
>=20
> class SaveExecutor implements IExecutor{
>     public function execute(callable $saveCommand){} }
>=20
> function foo(IExecutor $bar){
>     $bar->execute(command=3D>function(){});
> }
>=20
> In the function foo I use IExecutor as contract, I do not really care =
what the
> implementation is and thus I use command as named parameter. IMO that
> should be enough and I as a developer of the class SaveExecutor can =
choose
> whatever I like as parameter name to improve the readability.
> Sure, you could say the renaming above isn't really necessary and I =
could
> have used just $command instead of $saveCommand, but what if you use a
> third library and they named their parameters in the following way:
>=20
> interface ICustomer{
>     function createRelation($custId, $adrId, $main=3Dfalse); }
>=20
> Maybe you are able to guess that they expect an customer id, an =
address id
> and $main stands for whether this address is the main address of the
> customer or not.
> Right now I am not really too bothered about this bad naming of the
> parameters since I can use different ones in my implementation.
> Another use case could be, that one has to comply with some code
> guidelines which might claim, one needs to write a prefix before the
> parameter name if it is a scalar type. Something like $intCustId =
(puke)
>=20
> Without the check I can save the hassle to write a wrapper around the =
library
> to improve readability or to comply with some code guidelines (there =
are
> further use cases I suppose).
>=20
> I agree that if we introduce named parameters the parameter name has =
to
> be part of the contract, but as I said, I do not like the constraint =
and overkill it
> would add up. Personally I use named parameters very seldom and at the
> moment I would prefer the skipping parameters RFC. I see more =
drawbacks
> than benefits of named parameters in a type-unsafe language such as =
PHP.
>=20
> Cheers,
> Robert

I have a further reason why this check shouldn't be done and the =
implementation need to be changed:

namespace some\library {
    interface ILogger {
        function log($message);
    }
}

namespace another\library{
    interface ILogger{
	    function log($msg);
    }
}

namespace {
    class Logger implements some\library\ILogger, =
another\library\ILogger{
	    function log($message){}
    }
}

Valid code today, the check would be another BC break.