> -----Original Message-----
> From: Robert Stoll [mailto:rst...@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
>
> > -----Original Message-----
> > From: a...@adamharvey.name [mailto:a...@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 <dan...@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 — 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
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
