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
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
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
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
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
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
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,
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
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
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
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?
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
-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
-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
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
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 (
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.
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
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,
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'
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
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
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
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
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
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
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
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
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
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 (
+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
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
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.
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
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).
35 matches
Mail list logo
