> On 29 Mar 2015, at 17:56, Dan Ackroyd wrote:
>
> On 29 March 2015 at 12:28, Gints Murans 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 b
On 29 March 2015 at 12:28, Gints Murans 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 st
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 s
On Sun, Sep 8, 2013 at 1:26 AM, Gustavo Lopes wrote:
> On 06-09-2013 23:54, Nikita Popov wrote:
>
>> On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes > >wrote:
>>
>>>
>>> I think the correct course of action is just to drop support for extra
>>> named arguments. Just add an extra array argument to t
On Sat, Sep 7, 2013 at 9:52 AM, Pierre Joye 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,
On Fri, Sep 6, 2013 at 8:01 PM, Johannes Schlüter wrote:
> 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.p
On 06-09-2013 23:54, Nikita Popov wrote:
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes 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 thro
> -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] Name
> -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
; Subject: Re: [PHP-DEV] [RFC] Named parameters
>
> 2013/9/6 Adam Harvey
> >
> >
> > 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
On Sat, Sep 7, 2013 at 6:55 PM, Matthew Leverton 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 jus
On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
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
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
hi!
On Fri, Sep 6, 2013 at 6:39 PM, 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 gene
On Sat, Sep 7, 2013 at 5:29 AM, Matthew Leverton 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
Matthew Leverton wrote:
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue 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
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue 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
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 parameter
On Fri, Sep 6, 2013 at 11:23 PM, Gustavo Lopes wrote:
> 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
>> a
+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 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://w
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
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
On 6 September 2013 13:01, Dan Ackroyd 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 t
On Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov 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
On 6 September 2013 12:12, Dan Ackroyd 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...
>
> Wo
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 th
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' );
Whic
2013/9/6 Adam Harvey
>
>
> 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 do
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
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'
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
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 k
On 6 September 2013 09:39, Nikita Popov 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
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#o
35 matches
Mail list logo
