> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 — 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
>
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=>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:
interface ICustomer{
function createRelation($custId, $adrId, $main=false);
}
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
