Re: [PHP-DEV] [RFC] Named parameters
On 29 March 2015 at 12:28, Gints Murans g...@gm.lv wrote:
What happened to this RFC? This is a really great idea for php.
The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to
vote and was declined.
The 'named params' RFC (https://wiki.php.net/rfc/named_params) author
has been working on stuff they feel is more important.
Reading over some old code, this way it would be a lot easier to understand
what that second parameter boolean = true is:
You can do this right now, if you want to:
getIdByTitle('sample', $insert = true);
About syntax: $insert = true seems kind of confusing:
$insert = true;
getIdByTitle('sample', $insert = $insert)
You shouldn't need it for the case where you're actually already using
a parameter e.g. `getIdByTitle('sample', $insert);` already indicates
what the parameter is. The only place where you could argue this
syntax is needed is when you're passing in just a bare 'true' which
has no syntactic meaning associated with it.
That syntax works for all versions of PHP, so I guess a new syntax
that achieves the same thing is unlikely to be that popular an idea.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
Hi,
What happened to this RFC? This is a really great idea for php.
For example this function:
function getIdByTitle($title, $insert = false) {
// find record
// If no record find and $insert === true, insert new record and return
the id
// Return false
}
Reading over some old code, this way it would be a lot easier to understand
what that second parameter boolean = true is:
getIdByTitle('sample', insert = true)
than this way:
getIdByTitle('sample', true)
Also great for skipping default parameters.
About syntax: $insert = true seems kind of confusing:
$insert = true;
getIdByTitle('sample', $insert = $insert)
My preference would be either - getIdByTitle('sample', insert = $insert) or
getIdByTitle('sample', insert: $insert) with no parameter name prefixes.
—---
Gints Murāns
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On 29 Mar 2015, at 17:56, Dan Ackroyd dan...@basereality.com wrote:
On 29 March 2015 at 12:28, Gints Murans g...@gm.lv wrote:
What happened to this RFC? This is a really great idea for php.
The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to
vote and was declined.
Named params sounds a lot better idea instead of Skip Params. I would also
vote no for the later one.
The 'named params' RFC (https://wiki.php.net/rfc/named_params) author
has been working on stuff they feel is more important.
Sad. :( I don't know C that well to be able to help out.
Reading over some old code, this way it would be a lot easier to understand
what that second parameter boolean = true is:
You can do this right now, if you want to:
getIdByTitle('sample', $insert = true);
This is fundamentally wrong, this way a local variable is created and is really
not a solution for named parameters,
and parameter skipping, just a workaround to fool my self. :)
About syntax: $insert = true seems kind of confusing:
$insert = true;
getIdByTitle('sample', $insert = $insert)
You shouldn't need it for the case where you're actually already using
a parameter e.g. `getIdByTitle('sample', $insert);` already indicates
what the parameter is. The only place where you could argue this
syntax is needed is when you're passing in just a bare 'true' which
has no syntactic meaning associated with it.
That was only one example, how about: `getIdByTitle('sample', $insert =
empty($somethingElse));`,
its still confusing and for newcomers would be hard to understand, because
$insert isn't a variable, but the function's parameter.
Unless we look at it like we are setting function's parameters as variables,
but then it shouldn't have array element assignment operator (=).
Although `getIdByTitle('sample', $insert = true);` would most probably conflict
with variable assignment functionality, i.e. create local variables,
which shouldn't happen in case of named parameters.
Anyway my preference would be `getIdByTitle('sample', insert: true, type: 'x',
description: 'Something');`
That syntax works for all versions of PHP, so I guess a new syntax
that achieves the same thing is unlikely to be that popular an idea.
Well thanks for pointing it out, but this is really a good feature and I hope i
will be accepted sooner than later.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sun, Sep 8, 2013 at 1:26 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
On 06-09-2013 23:54, Nikita Popov wrote:
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
I think the correct course of action is just to drop support for extra
named arguments. Just add an extra array argument to the function and you
have equivalent functionality without having to go through these edge
cases.
Dunno, personally I don't have a strong need for the extra named args.
That's something Stas considered important (in the discussing re
skipparams
RFC). Would be interesting to know for what they are currently used in
Python/etc and whether those use cases are sufficiently important to us.
The advantages would have to be very significant in order to justify
breaking all the call forwarding code out there relying on call_user_func()
and func_get_args().
It also unnecessary complicates the variadics calls for the callee that
now receives a potentially non-numeric array. The caller may have slightly
better syntax, but there being no information on support of extra named
parameters on the signature is an extra complication. And at this point I
haven't seen any convincing argument as to how this is more than marginally
better than an extra array argument for the caller and any better at all
for the callee.
I think you mentioned yourself why support for unknown named params (in the
following kwargs) is necessary: Call forwarding. If you want to do a
forwarded call with named params you need some kind of kwargs support.
I don't see how we can support call-forwarding with named params for
existing code (without breaking BC in cufa), but we should at least be able
to implement it in new code. The ...$params syntax allows this. E.g. here's
a simple example where __invoke is forwarded to another method:
/* OLD: No named params support */
public function __invoke() {
call_user_func_array([$this, 'someMethod'], func_get_args());
}
/* NEW: With named params support */
public function __invoke(...$params) {
$this-someMethod(...$params);
}
This works easily for __invoke (not sure if it works right now, but easy
enough to support), but not so well with __call and __callStatic. E.g. if
you have something like this currently:
/* Forward unknown method calls to the method name with prefix _
* (to support method names that are keywords) */
public function __call($method, $args) {
call_user_func_array([$this, '_' . $method], $args);
}
You can not directly translate that to code supporting named args, because
this makes use of an $args array rather than variadic arguments.
I'm wondering whether it's okay to add the unknown named params to $args
here. For old code this will work. If new code tries to use named params
with old code this would also run, but not have the correct result (no
error that is).
Alternative I could allow __call declarations with __call($method,
...$args) and only in that case collect named args.
Not sure about any of this, didn't really consider the forwarding issue
previously.
Nikita
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 8:01 PM, Johannes Schlüter johan...@schlueters.dewrote: From the explanation it sounds like there shouldn't be a high cost, but as fcalls are a key operation and already quite slow I wonder if you could share some benchmarks. (non-debug-non-tsrm-build) A good start might be Zend/bench.php. And I understand this is not the final patch but good to have the order of magnitude. I didn't see any obvious regressions from Zend/bench.php and this is also what I would expect: The parts relating to named arguments are hidden behind optype-specialization of the send opcodes, so those shouldn't affect perf. There is also a bit extra code in do_fcall_common to handle passing of additional unknown named params, but that's also just two branches in a large mix of other code. So it really shouldn't impact performance and judging from Zend/bench.php it doesn't. I also did a very quick test how a normal call compares to one using named params. Right now the latter is about 25% slower. But I'm pretty sure this number can be improved a good bit, e.g. I'm not yet making use of CACHED_PTR to store the argument number of the parameter. Nikita
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 9:52 AM, Pierre Joye pierre@gmail.com wrote: In no particular order: . Warning: Cannot pass positional arguments after named arguments. Aborting argument unpacking in %s on line %d Would it make more sense to make it a fatal error? As the code will likely not work as expected, at all. It could be a bit too harsh but as it is a new feature, there is no BC impact and ensure good usage. I agree that continuing the function call in that case is a bad idea, but I also really dislike throwing fatal errors when dynamic constructors are used. An exception would be optimal here (no continued function call, but easily recoverable), but I know I'm not allowed to introduce those... . would it make sense to have an alternative zend API to fetch one or more argument using its name? I can see a couple of usages for such a function I provide this function: ZEND_API int zend_get_arg_num(zend_uint *arg_num_target, zend_function *fn, char *name, int name_len, zend_ulong hash_value TSRMLS_DC); Using it you can get the argument number from a parameter name and based on that lookup the value of the argument as usual. Is that sufficient? - It would be nice to add (later once the RFC is more stable) docs about which impacts and changes are expected for extension developers Yes, sure :) - Do you have a fork for this RFC? Much easier to test, create snaps, etc. Yes, it's the namedParams branch of my github fork: https://github.com/nikic/php-src/tree/namedParams Nikita
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 5:29 AM, Matthew Leverton lever...@gmail.com wrote:
The big difference here is if I accept an options array, I understand
that the keys are important and would never break backward
compatibility by changing a parameter name. This isn't a case of if
you don't like it, then don't use it because every function I create
now has to respect the possibility of accepting named parameters,
whether I care about it or not. And I sure hope every function I call
is created by and maintained by somebody with those same
sensibilities.
My opinion is that this really isn't as cool as it sounds, especially
since we have short array syntax. Again, I don't really care if it's
accepted into PHP, but I think it will be more of a minor nuisance for
me than anything else.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, all
Would it be an option, to change the way named functions are declared?
This way you would mark a function explicitly as having named
parameters.
This increases the learning-curve for PHP, but for me, it seems a
valid approach ...
An example that comes to my mind, is to call this a named function
... Feel free to add a better keyword.
This would then look something like this:
named function functionHavingNamedParamsEnabled($firstParam, $secondParam) {}
function functionHavingNamedParamsDisabled($firstParam, $secondParam) {}
functionHavingNamedParamsEnabled( secondParam = secondValue,
firstParam = firstValue);
// Will work ...
functionHavingNamedParamsDisabled( secondParam = secondValue,
firstParam = firstValue);
// Will not work, because this function is not declared to support named params.
Just an idea for a compromise ..
What I don't like here would be if I'd have to add some cryptographic
char instead of a keyword to the definition of the function.
I, too, am quite neutral to this feature.
Bye,
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
hi! On Fri, Sep 6, 2013 at 6:39 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Love it and always wanted it! Thanks for working on that! I quickly look at the patch and related phpt, so feel free to nicely correct me if I ask something already covered :) In no particular order: . Warning: Cannot pass positional arguments after named arguments. Aborting argument unpacking in %s on line %d Would it make more sense to make it a fatal error? As the code will likely not work as expected, at all. It could be a bit too harsh but as it is a new feature, there is no BC impact and ensure good usage. . would it make sense to have an alternative zend API to fetch one or more argument using its name? I can see a couple of usages for such a function - It would be nice to add (later once the RFC is more stable) docs about which impacts and changes are expected for extension developers - Do you have a fork for this RFC? Much easier to test, create snaps, etc. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On 06/09/2013 20:58, Matthew Leverton wrote: What I don't like about named parameters is that if I build a library, now even my parameter names are unchangeable if I don't want to break any backward compatibility, since I never know if somebody will decide to call my single parameter method with named parameters. Are we prepared to go through every PHP function and make sure the names of the parameters are set in stone before this feature would go live? The position of parameters and the name of the function must already be maintained... I dont see why appropriately naming variables is such a burden. Of course, people who use the feature are not going to assume pre-existing code is fair-game from named parameters. As with most new php features, it's to improve code written in the future. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
mich...@mjburgess.co.uk wrote:
The position of parameters and the name of the function must already be
maintained... I dont see why appropriately naming variables is such a
burden.
I wouldn't necessarily make this objection if this were a day-1
feature. But it does bother me somewhat that all of a sudden code
retro-actively starts supporting named parameters.
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' = 1, 'string' = 'Hello World');
Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere. So that's why I call this a nuisance. It just seems like a
very marginal gain for lots of potential headaches.
But I don't mean to make a mountain out of a molehill. After giving it
some thought, I'd like some consideration to be given to providing an
explicit syntax in the RFC at least so people consider all
alternatives.
I just don't think that giving people the ability to call a function
with two well ordered parameters by using named parameters is worth
causing all future code to diverge into two drastically different
calling styles.
My strong preference would be a syntax that separates the two types of
parameters, such as the following:
function func($a, $b, ...$params, [$c = 'foo', $d = 'bar'])
{
}
func($a, $b, $extra, 'd' = 'override');
Here $a and $b are not named parameters and must be present. Extra
positional parameters are sent to $params. The parameters enclosed in
square brackets must be passed in by name as the last parameters, but
can be omitted.
I don't like the $ on the named parameter when calling because it
implies that this works:
$d = 'c';
func($a, $b, $extra, $d = 'override');
Now is 'c' overridden or 'd'?
So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 6:55 PM, Matthew Leverton lever...@gmail.com wrote:
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' = 1, 'string' = 'Hello World');
Hi, Matthew
Wouldn't this just fail, because one required parameter is omitted?
You can just leave out parameters, that have a default-value.
Otherwise it's treated like calling:
substr('Hello World');
// Warning: substr() expects at least 2 parameters, 1 given in php
shell code on line 1
I would return the same, even so the parameter-count is 2, but the 2nd
parameter is missing, but required.
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Named parameters
Hi Nikita
First of all, thanks for your proposal.
I'd like to make some comments, see below.
-Original Message-
From: Lazare Inepologlou [mailto:linep...@gmail.com]
Sent: Friday, September 06, 2013 7:55 PM
To: Adam Harvey
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Named parameters
2013/9/6 Adam Harvey ahar...@php.net
Variadics/splat: collecting both named and positional arguments into
one array seems reasonable to me. I think the main use case there
would be option parameters, which you'd have to validate anyway, so
positional parameters would be dealt with at that point — I don't see
separate arrays as conferring any great advantage in terms of
validating parameters, and it's no simpler conceptually.
There is a small drawback. Suppose this code:
function foo( $bar = 0 , ...$args ){}
foo( bart = 3 ); // misspelled name
According to the RFC, any unknown argument name will fall into the $args
array, making the above code valid. As this cannot be verified statically, it
is a
possible source of bugs.
Lazare INEPOLOGLOU
Ingénieur Logiciel
I agree with Lazare, it seems wrong to me to mix *args and **kwargs and put
everything in one argument. Especially because this will hide bugs for sure,
but also because if I want to use *args then I do not want necessarily support
**kwargs as well (as mentioned in your cons).
Btw did I miss something? I could not read anything about **kwargs in your
variadics RFC. Because you do not want to introduce it together with *args?
I now assume you do not want to introduce **kwargs and handle everything with
*args. That's why you came up with the idea to put everything in *args, right?
I'd like to outline an example where **kwargs would be very useful. Sorry,
somehow off-topic but that's just because this RFC refers to other RFCs which
are not yet accepted. I think it's not a good idea to start mixing several RFC.
It almost seems like variadics, argument unpacking and named parameters can
only coexist together. But anyway... now I go the same way :P
**kwargs is very useful if you want to have a type for *args and some options
for **kwargs
Let's say I have defined a function which renders an arbitrary number of
contact details (one contact per row) and you want to be able to pass in some
additional html attributes which shall be applied for each tr.
---
function renderAsTable(array $htmlAttributes, Contact ...$args){}
renderAsTable(['class' = 'someClass', 'validate'='true'], $contact1,
$contact2);
vs.
function renderAsTable(Contact ...$args, =...$htmlAttributes){} // =...
should stand for **kwargs, I do not like this syntax but nothing else came into
my mind right now
renderAsTable($contact1, $contact2, 'class' = 'someClass', 'validate'='true');
---
I know, the first syntax doesn't seem to be too bad yet (apart from ['class' =
'someClass', 'validate'='true'] is almost looking like named arguments, maybe
= isn't a good choice and we should prefer something else?) but consider when
you combine it with argument unpacking
---
renderAsTable(array_merge($arr, ['class' = 'someClass', 'validate'='true']),
], $contact1, $contact2);
vs.
renderAsTable($contact1, $contact2, 'class' = 'someClass', 'validate'='true',
...$arr);
---
I prefer the second version and I guess you agree that variadics shall be
introduced to reduce array_merge. Thus it seems logical to me to introduce
**kwargs as well and therefore I would not mix them and put everything only in
one argument. Otherwise you will have problems to introduce **kwargs later on.
You could argue one could write the second version and handle everything in the
function. But I am pretty sure that no one wants to have such an overhead
either. Something like:
function renderAsTable(...$args){
$htmlAttributes = []
$contacts = []
foreach($args as $key = $value){
if($value instanceof Contact){
$contacts[] = $value;
} else {
$htmlAttributes[] = $value;
}
}
//now do your stuff
}
You could also argue, that one just need to write the function in a different
way:
function renderAsTable(array $contacts, ...$htmlAttributes){}
Might work as a workaround in this case, but then I lose the ability to have a
type checked array ;-)
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Named parameters
-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
Re: [PHP-DEV] [RFC] Named parameters
On 06-09-2013 23:54, Nikita Popov wrote:
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
I think the correct course of action is just to drop support for extra
named arguments. Just add an extra array argument to the function and you
have equivalent functionality without having to go through these edge cases.
Dunno, personally I don't have a strong need for the extra named args.
That's something Stas considered important (in the discussing re skipparams
RFC). Would be interesting to know for what they are currently used in
Python/etc and whether those use cases are sufficiently important to us.
The advantages would have to be very significant in order to justify
breaking all the call forwarding code out there relying on
call_user_func() and func_get_args().
It also unnecessary complicates the variadics calls for the callee that
now receives a potentially non-numeric array. The caller may have
slightly better syntax, but there being no information on support of
extra named parameters on the signature is an extra complication. And at
this point I haven't seen any convincing argument as to how this is more
than marginally better than an extra array argument for the caller and
any better at all for the callee.
I also disagree about your idea about how to handle changed parameter
names. Having an E_ERROR here is absolutely unacceptable. This would be a
major BC break (not to mention inconsistent with the other other signature
mismatches are handled).
Yes, I certainly do not want to throw any fatal-ish error here. Maybe I
didn't make that clear in the RFC. (What do you mean with inconsistent
with the other other signature mismatches are handled though? For
signature mismatches involving interfaces we currently use fatal error.
Signature mismatches between classes are E_STRICT.)
I meant the E_STRICT on rather more worrying situations like:
class A { function a(array $a) {} }
class B extends A { function a(SplArray $a) {} }
In fact, I think ANY message here would waste millions of $currency in man
hours. I can't think of any easy solution there. An alternative solution
would be to keep a flag on whether argument names changed and refuse to
accept named arguments in the case a call is made to an instance whose
class or some its parents changed parameter names, but this comes with some
memory penalty.
Eh, I don't know. Getting an error at the call-site is already too late.
You'll get one anyway because the parameter name doesn't exist. Unless
mismatching parameter names are exceedingly common, I'd think a lowly
E_STRICT level error would be bearable.
Too late for what? If there is a mismatch but named arguments are not
used, there is no problem with the code (if you don't consider named
parameters not being permitted a problem). In any case, a more specific
error is better than a generic one.
That said, I'm on the fence here because it's not really nice to have
named parameters being permitted in a call to method A::b() but having
the same call forbidden to B::b(), where B extends A.
Regards
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On 6 September 2013 09:39, Nikita Popov nikita@gmail.com wrote:
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Questions (
https://wiki.php.net/rfc/named_params#open_questions) in particular.
Thanks for proposing this. I haven't looked at the patch yet, but I'm
all for the feature.
My thoughts on your open questions:
Syntax: I suspect this will end up having to go to a vote (classic
bikeshed), but I'm on the func('foo' = 'bar') train. :foo doesn't
make sense in a PHP context (we'd have to implement that across the
language, not just for function calls), : as a key-value separator
would only work if it was also supported in array literals, and =
feels a little wrong for this. I don't really like the unquoted
parameter names so much; it's inconsistent with array literals and
bare words as strings is something that's been discouraged for a long
time.
Variadics/splat: collecting both named and positional arguments into
one array seems reasonable to me. I think the main use case there
would be option parameters, which you'd have to validate anyway, so
positional parameters would be dealt with at that point — I don't see
separate arrays as conferring any great advantage in terms of
validating parameters, and it's no simpler conceptually.
call_user_func_array: for consistency, we might want to consider
adding an analogue function that deals with named parameters, even
though it would work via $callable(...$kwargs).
Contracts: I agree with you, basically — it would have to be an
E_STRICT or thereabouts, with the possibility of revisiting come a
hypothetical PHP 6.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
Dan, That's a good question as well, with the current $var syntax I'm assuming NO. You're using the $var3 name as a key, not as the $paramToOverride value. Maybe the collon could be used here? $paramToOverride = 'var3'; testFunction(:$paramToOverride = 'bar'); // Colon before $ would make the key :var3 ? Then again, I like the colon syntax instead of = to assign fn(key: val) pairs for readability/clearer separation of array syntax, so that would probably make: testFunction(:$paramToOverride: 'bar'); As my suggestion and I'm not sure I like it... :x -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
I like! My preference on syntax is; test(:foo = oof, :bar = rab); I don't think; test(foo = oof, bar = rab); denotes enough emphasis on any part in-particular, and the downsides of other implementations are mentioned, such as variable names and collisions with reserved keywords. Thanks, Gareth On 6 September 2013 17:39, Nikita Popov nikita@gmail.com wrote: Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
Hi Nikita,
Will it be possible to set the named parameter through using a parameter?
i.e. can you do:
function multipleParamFunction($var1 = null, $var2 = null, $var3 = null,
$var4 = null) {
//...
}
$paramToOverride = 'var3';
testFunction($paramToOverride = 'bar');
which would override 'var3' in the function.
The syntax for setting a named parameter by a parameter clashes with some
of the suggested syntaxes. Even if it isn't going to be possible to support
this currently, it would be a good idea to not use a syntax that prevents
support of this in the future.
cheers
Dan
On Fri, Sep 6, 2013 at 5:39 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet complete. I mainly want to have
feedback on the idea in general and on the Open Questions (
https://wiki.php.net/rfc/named_params#open_questions) in particular.
Thanks,
Nikita
Re: [PHP-DEV] [RFC] Named parameters
Hi, On Fri, 2013-09-06 at 18:39 +0200, Nikita Popov wrote: Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. From the explanation it sounds like there shouldn't be a high cost, but as fcalls are a key operation and already quite slow I wonder if you could share some benchmarks. (non-debug-non-tsrm-build) A good start might be Zend/bench.php. And I understand this is not the final patch but good to have the order of magnitude. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
2013/9/6 Adam Harvey ahar...@php.net
Variadics/splat: collecting both named and positional arguments into
one array seems reasonable to me. I think the main use case there
would be option parameters, which you'd have to validate anyway, so
positional parameters would be dealt with at that point — I don't see
separate arrays as conferring any great advantage in terms of
validating parameters, and it's no simpler conceptually.
There is a small drawback. Suppose this code:
function foo( $bar = 0 , ...$args ){}
foo( bart = 3 ); // misspelled name
According to the RFC, any unknown argument name will fall into the $args
array, making the above code valid. As this cannot be verified statically,
it is a possible source of bugs.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Re: [PHP-DEV] [RFC] Named parameters
Regarding variable parameter names; if the syntax was:
function foo( $firstParameter ) { ... }
foo( $firstParameter= 'foo' );
Then the double-dollar syntax would seem the obvious choice to me:
function foo( $firstParameter ) { ... }
$param = 'firstParameter';
foo( $$param = 'whatever' );
Which is no less readable than anywhere else the double-dollar is
allowed... :-p
--G
Re: [PHP-DEV] [RFC] Named parameters
Hi Nikita, If named parameters are introduced, signature validation should include parameter names. Throwing a fatal error (for the interface/class combination) would break backwards compatibility though. We could use some lower error type... Would it be possible to set the error level through an ini setting? Or disable it entirely? People who are writing new code that is aware of named parameters should want a fatal error for any coding mistake that violates the contract. People who are supporting legacy code that doesn't use named parameters should be able to upgrade to the latest version of PHP without having to refactor an entire code base or suppressing huge numbers of compiler warnings. cheers Dan On Fri, Sep 6, 2013 at 5:39 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks, Nikita
Re: [PHP-DEV] [RFC] Named parameters
On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com wrote: If named parameters are introduced, signature validation should include parameter names. Throwing a fatal error (for the interface/class combination) would break backwards compatibility though. We could use some lower error type... Would it be possible to set the error level through an ini setting? Or disable it entirely? I've said this before, but to reiterate it: I'd be a huge -1 on anything that involves configurable language behaviour. It's a support nightmare, and I'm glad those days are now mostly over. People who are writing new code that is aware of named parameters should want a fatal error for any coding mistake that violates the contract. 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. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov nikita@gmail.com wrote: The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. I feel like this will just encourage more core PHP functions with an unmanageable number of parameters. Will there be any proposed guidelines to how future functions will make use of named parameters? e.g., Will we see native functions with 20 arguments? What I don't like about named parameters is that if I build a library, now even my parameter names are unchangeable if I don't want to break any backward compatibility, since I never know if somebody will decide to call my single parameter method with named parameters. Are we prepared to go through every PHP function and make sure the names of the parameters are set in stone before this feature would go live? So I'm neutral to this proposal, as I would never purposefully build a function that is so convoluted that it needs named parameters, but I understand that's how some people like to write code, and it could be useful in extreme cases. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
George Bond wrote:
Then the double-dollar syntax would seem the obvious choice to me:
foo( $$param = 'whatever' );
Which is no less readable than anywhere else the double-dollar is
allowed... :-p
For the simple case I agree having double $$ signs is not that bad, but it
would get nasty for anything other than a simple variable. e.g. if the
param name was in an array:
$searchKeys[] = 'firstParameter'
$searchValues[] = 25;
foo( ${$searchKeys[0]} = $searchValues[0] );
which is definitely less legible than:
foo( $searchKeys[0] = $searchValues[0] );
cheers
Dan
On Fri, Sep 6, 2013 at 6:44 PM, George Bond
happy.melon.wiki...@gmail.comwrote:
Regarding variable parameter names; if the syntax was:
function foo( $firstParameter ) { ... }
foo( $firstParameter= 'foo' );
Then the double-dollar syntax would seem the obvious choice to me:
function foo( $firstParameter ) { ... }
$param = 'firstParameter';
foo( $$param = 'whatever' );
Which is no less readable than anywhere else the double-dollar is
allowed... :-p
--G
Re: [PHP-DEV] [RFC] Named parameters
Hi Adam 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? 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). cheers Dan On Fri, Sep 6, 2013 at 8:16 PM, Adam Harvey ahar...@php.net wrote: On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com wrote: If named parameters are introduced, signature validation should include parameter names. Throwing a fatal error (for the interface/class combination) would break backwards compatibility though. We could use some lower error type... Would it be possible to set the error level through an ini setting? Or disable it entirely? I've said this before, but to reiterate it: I'd be a huge -1 on anything that involves configurable language behaviour. It's a support nightmare, and I'm glad those days are now mostly over. People who are writing new code that is aware of named parameters should want a fatal error for any coding mistake that violates the contract. 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. Adam
Re: [PHP-DEV] [RFC] Named parameters
On 06-09-2013 18:39, Nikita Popov wrote: I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. I like the idea, but I think you're approaching this the wrong way. In my opinion, you should emulate the current behavior as close as possible. For instance: func_get_args() will not include the missing offsets in the resulting array Why not? Why not include the default value in the missing offset? This is not possible for internal functions, but I've talked in depth about the problems that skipping parameters introduces and they're not different here (though I should say those problems are not intractable and I think the cost/benefit analysis here is completely different). func_get_arg($n) will throw its usual “Argument %ld not passed to function” warning and return false Again, why not return the default value? This section is also problematic: All three functions are also oblivious to the collection of unknown named arguments by variadics. func_get_args() will not return the collected values and func_num_args() will not include them in the argument count. (...) I think the correct course of action is just to drop support for extra named arguments. Just add an extra array argument to the function and you have equivalent functionality without having to go through these edge cases. I also disagree about your idea about how to handle changed parameter names. Having an E_ERROR here is absolutely unacceptable. This would be a major BC break (not to mention inconsistent with the other other signature mismatches are handled). In fact, I think ANY message here would waste millions of $currency in man hours. I can't think of any easy solution there. An alternative solution would be to keep a flag on whether argument names changed and refuse to accept named arguments in the case a call is made to an instance whose class or some its parents changed parameter names, but this comes with some memory penalty. In conclusion, if you drop one dubious feature and present to the callee the same state as before (as if the caller had passed the skipped parameters with the default arguments), this would ease the implementation and the transition, especially for userland code. Regards -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
+1 to named params. Please please please. :) = is my vote for syntax. Makes sense. Doesn't make sense to introduce another way to express something we've been used to for years with key = value, and is it that important to save one character per assignment? On Sep 6, 2013, at 9:39 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: I like the idea, but I think you're approaching this the wrong way. In my opinion, you should emulate the current behavior as close as possible. For instance: func_get_args() will not include the missing offsets in the resulting array Why not? Why not include the default value in the missing offset? This is not possible for internal functions, but I've talked in depth about the problems that skipping parameters introduces and they're not different here (though I should say those problems are not intractable and I think the cost/benefit analysis here is completely different). func_get_arg($n) will throw its usual “Argument %ld not passed to function” warning and return false Again, why not return the default value? These suggestions sound very reasonable. It would require some way to get the default value though. So unless we want to start storing them in the arginfo (meh), I'd have to extract them from the ZEND_RECV_INIT opcodes. Which probably is okay, as we're already doing it in Reflection. This section is also problematic: All three functions are also oblivious to the collection of unknown named arguments by variadics. func_get_args() will not return the collected values and func_num_args() will not include them in the argument count. (...) I think the correct course of action is just to drop support for extra named arguments. Just add an extra array argument to the function and you have equivalent functionality without having to go through these edge cases. Dunno, personally I don't have a strong need for the extra named args. That's something Stas considered important (in the discussing re skipparams RFC). Would be interesting to know for what they are currently used in Python/etc and whether those use cases are sufficiently important to us. I also disagree about your idea about how to handle changed parameter names. Having an E_ERROR here is absolutely unacceptable. This would be a major BC break (not to mention inconsistent with the other other signature mismatches are handled). Yes, I certainly do not want to throw any fatal-ish error here. Maybe I didn't make that clear in the RFC. (What do you mean with inconsistent with the other other signature mismatches are handled though? For signature mismatches involving interfaces we currently use fatal error. Signature mismatches between classes are E_STRICT.) In fact, I think ANY message here would waste millions of $currency in man hours. I can't think of any easy solution there. An alternative solution would be to keep a flag on whether argument names changed and refuse to accept named arguments in the case a call is made to an instance whose class or some its parents changed parameter names, but this comes with some memory penalty. Eh, I don't know. Getting an error at the call-site is already too late. You'll get one anyway because the parameter name doesn't exist. Unless mismatching parameter names are exceedingly common, I'd think a lowly E_STRICT level error would be bearable. Nikita
Re: [PHP-DEV] [RFC] Named parameters
Matthew Leverton wrote: What I don't like about named parameters is that if I build a library, now even my parameter names are unchangeable if I don't want to break any backward compatibility, since I never know if somebody will decide to call my single parameter method with named parameters. Are we prepared to go through every PHP function and make sure the names of the parameters are set in stone before this feature would go live? This is already the case. In libraries that accept options via an array, those array keys are pretty much set in stone (although you can map them if you need to change a key). All this does is add first-class support in the language. Huge +1 for this feature and thank you to Nikita for working on the RFC. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue li...@rotorised.com wrote: Matthew Leverton wrote: This is already the case. In libraries that accept options via an array, those array keys are pretty much set in stone (although you can map them if you need to change a key). The big difference here is if I accept an options array, I understand that the keys are important and would never break backward compatibility by changing a parameter name. This isn't a case of if you don't like it, then don't use it because every function I create now has to respect the possibility of accepting named parameters, whether I care about it or not. And I sure hope every function I call is created by and maintained by somebody with those same sensibilities. My opinion is that this really isn't as cool as it sounds, especially since we have short array syntax. Again, I don't really care if it's accepted into PHP, but I think it will be more of a minor nuisance for me than anything else. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
Matthew Leverton wrote: On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue li...@rotorised.com wrote: Matthew Leverton wrote: This is already the case. In libraries that accept options via an array, those array keys are pretty much set in stone (although you can map them if you need to change a key). The big difference here is if I accept an options array, I understand that the keys are important and would never break backward compatibility by changing a parameter name. This isn't a case of if you don't like it, then don't use it because every function I create now has to respect the possibility of accepting named parameters, whether I care about it or not. And I sure hope every function I call is created by and maintained by somebody with those same sensibilities. My opinion is that this really isn't as cool as it sounds, especially since we have short array syntax. Again, I don't really care if it's accepted into PHP, but I think it will be more of a minor nuisance for me than anything else. I'll second that statement. It will be more reason for me to stop following PHP 'upgrades' in the future. I'm already holding off 5.5 as it gives me nothing that I want. This would be a reason to make that permanent. I would add that one of the reasons I moved TO PHP was the fact that it did not have the overhead of named parameters, amongst other things which have also been lost over the last few years. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
