Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68957
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>
In-Reply-To: <CADajX4Cwi07809+AF5G+qX38JYc4Y_GaNv=6-T6RhCF1G5isqA@mail.gmail.com>
Date: Sun, 8 Sep 2013 00:35:35 +0200
Message-ID: <005701ceac1a$9369ba70$ba3d2f50$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIRCtTWl6J3njxJ6HEYny8b14HHdQHSzPeGAdoNKukDGYexEwGxrYk5mPJNNuA=
Content-Language: de-ch
Subject: RE: [PHP-DEV] [RFC] Named parameters
From: rstoll@tutteli.ch ("Robert Stoll")

> -----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
>=20
> 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?
>=20
> 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.
>=20
> > 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).
>=20
> 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.
>=20
> Adam
>=20

Heya,

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

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.

Following an example to outline why I do not like the check:

interface IExecutor{
    function execute(callable $command);
}

class SaveExecutor implements IExecutor{
    public function execute(callable $saveCommand){}
}

function foo(IExecutor $bar){
    $bar->execute(command=3D>function(){});
}

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);
}

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)

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).

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.

Cheers,
Robert