On 5/27/12 10:27 AM, Mathias Grimm wrote:
> in response to https://wiki.php.net/rfc/skipparams I want to suggest
> something as depicted below:
>
> function very_long_params(name:$n, age:$a, other:$o)
The goal of this proposal is not to introduce named parameters. If we
ever do introduce named pa
On Sun, May 27, 2012 at 6:14 PM, William Betts wrote:
> On Sun, May 27, 2012 at 11:28 AM, Mathias Grimm >wrote:
>
> > Named parameter in the same way that goto does, with labels. A labeled
> > parameter...
> > But there always some drawbacks... such as mix named and conventional
> > parameters. I
On Sun, May 27, 2012 at 11:28 AM, Mathias Grimm wrote:
> Named parameter in the same way that goto does, with labels. A labeled
> parameter...
> But there always some drawbacks... such as mix named and conventional
> parameters. I think that you just chose one way and use, not allowing mix
> these
Named parameter in the same way that goto does, with labels. A labeled
parameter...
But there always some drawbacks... such as mix named and conventional
parameters. I think that you just chose one way and use, not allowing mix
these two ways.
I also think that should exists a strict way to wri
NOTE: Although related/solving some of the same problems; skipping optional
parameters (several commas or using 'default' keyword) is different from
using named parameters.
And both have different supporters/haters over each change.
I wouldn't like to restart the whole debate over the KISS, "Not t
in response to https://wiki.php.net/rfc/skipparams I want to suggest
something as depicted below:
function very_long_params(name:$n, age:$a, other:$o)
{
}
or
function very_long_params(:name = null, :age, :other)
{
$name = trim($name);
...
}
$result = very_long_params(age:20, other:'foo',
On 2012-04-19, Yasuo Ohgaki wrote:
> Just a though for named parameter, since it seems
> its becoming a relevant topic now.
>
> 2012/4/18 Daniel Macedo :
> > I agree with this! But for short array syntax we kept the => as in
> > $array = ["foo" => "bar"];
> > Not sure if this was a limitation,
Hi,
Just a though for named parameter, since it seems
its becoming a relevant topic now.
2012/4/18 Daniel Macedo :
> I'll keep going offtopic a bit more.
> I would rather see named parameters implemented *prior* to this.
> Although maybe not instead, I think both might have their place.
>
> On We
Hi!
> Before addressing the points individually, I have to reiterate that
> internal functions have no concept of default values. I think this
I disagree. Most of them certainly do, for example, look at strpos
documentation:
int strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )
$
On Wed, 18 Apr 2012 23:35:37 +0200, Stas Malyshev
wrote:
Before addressing the points individually, I have to reiterate that
internal functions have no concept of default values. I think this
proposal or a named arguments proposal is *really* ill-advised without
introducing proper default values
Hi!
> Not sure what you mean here. What is this "varargs return"? As far as I
zend_parse_parameters has varargs options. See how var_dump is implemented.
> the number of arguments actually passed. But even if it returned the
> number of arguments passed, it would be irrelevant because you wo
On Wed, 18 Apr 2012 22:34:23 +0200, Stas Malyshev
wrote:
Hi!
This would cause a lot of problems. Basically, all the functions that
rely
on ZEND_NUM_ARGS() will have to be changed. You can't tell if a
parameter
was passed or not by relying on it.
ZEND_NUM_ARGS() would probably work sin
Hi!
> This would cause a lot of problems. Basically, all the functions that rely
> on ZEND_NUM_ARGS() will have to be changed. You can't tell if a parameter
> was passed or not by relying on it.
ZEND_NUM_ARGS() would probably work since IIRC it relies on stack size,
not on varargs return. Yes, th
On Wed, 18 Apr 2012 00:54:41 +0200, Stas Malyshev
wrote:
[snip]
https://wiki.php.net/rfc/skipparams
[snip]
«For internal functions, parameter parser will ignore the NULLs, thus
leaving the defaults supplied by the caller intact. Again, skipping
non-optional parameter is an error.»
This woul
Hi!
> I'll keep going offtopic a bit more.
> I would rather see named parameters implemented *prior* to this.
I'd rather see named parameters implemented already in 5.0. But somehow
that didn't happen :) It's on my todo list though if nobody beats me to it.
--
Stanislav Malyshev, Software Archit
On Tue, April 17, 2012 6:23 pm, Jordi Boggiano wrote:
> On 18.04.2012 00:54, Stas Malyshev wrote:
>> One of the annoying things I've encountered in working with PHP was
>> dealing with functions having long optional parameter lists,
>> especially
>> if you need to change only the last one - you hav
I like the idea. In fact I started to implement it some time ago, but your
patch is really cleaner than mine :)
Otherwise I would prefer to insert the default keyword to make the code
more readable. It might be hard to count when you have something like
function(true);
P.
On 17 April 2012 18
Daniel Macedo wrote:
I am sorry Lester, but you seem to be getting the "optional parameter"
backwards.
You are supposed to use the optional parameters when it's up to the
library/function definition to determine it's value, not when the
value is what you want for this particular function call!
+1.
I LIKE https://wiki.php.net/rfc/namedparameters , please change OLD decide.
-邮件原件-
发件人: Ferenc Kovacs [mailto:tyr...@gmail.com]
发送时间: 2012年4月18日 15:19
收件人: Stas Malyshev
抄送: PHP Internals
主题: Re: [PHP-DEV] [RFC] skipping optional parameters
On Wed, Apr 18, 2012 at 12:54 AM, Stas
I am sorry Lester, but you seem to be getting the "optional parameter"
backwards.
You are supposed to use the optional parameters when it's up to the
library/function definition to determine it's value, not when the
value is what you want for this particular function call!
What you seem to be cur
On 04/18/2012 01:05 PM, Arvids Godjuks wrote:
> I personally would vote for the "default" keyword if I want to skip the
> param rather than just doing it with , - the keyword approach is much more
> readable and error prone.
I also agree that the "comma-train" (multiple commas without anything
inb
I personally would vote for the "default" keyword if I want to skip the
param rather than just doing it with , - the keyword approach is much more
readable and error prone.
Daniel Macedo wrote:
function fn1($a = false, $b = nul, $c = 1)
{
var_dump($a, $b. $c);
}
// your idea
fn1(NULL, NULL, 10), // NULL, NULL, 10
// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10
Of cause one little problem here is if the default gets changed in the 'l
On 18 April 2012 11:38, Daniel Macedo wrote:
> You can't do that, NULL is a perfectly acceptable value to pass into a
> function, you wouldn't be able to know when you wanted to pass NULL or
> use the default value, e.g.:
>
>
You totally missed the point: hinting, not-so-subtly, at the
long-estab
You can't do that, NULL is a perfectly acceptable value to pass into a
function, you wouldn't be able to know when you wanted to pass NULL or
use the default value, e.g.:
function fn1($a = false, $b = nul, $c = 1)
{
var_dump($a, $b. $c);
}
// your idea
fn1(NULL, NULL, 10), // NULL, NULL, 10
//
On 18 April 2012 10:25, Daniel Macedo wrote:
> But I couldn't support the comma train, for the insane «lots of
> parameters» case, would hate to read some fn($some $var,,, $other)
> call.
> I'd rather reuse a reserved word like 'default' (or even get a shorter
> one?)
>
>
How about "null"? (T
Adam Jon Richardson wrote:
I disagree with the suggestion that the "real" solution is to refactor
functions. Is a function with 3 parameters too long?
function foo($val1, $val2 = true, $val3 = false) { /* code */}
If I want to pass in a value to the third argument but keep the default
value for
I'll keep going offtopic a bit more.
I would rather see named parameters implemented *prior* to this.
Although maybe not instead, I think both might have their place.
On Wed, Apr 18, 2012 at 08:43, Yasuo Ohgaki wrote:
>
> Something like
>
> setcookie( name:'mycookie', value:'abc', secure:true, ht
Am 18.04.2012 09:18, schrieb Ferenc Kovacs:
On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev
wrote:
Hi!
One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists,
especially
if you need to change only the last one - you hav
hi Stas,
On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev wrote:
> create_query("deleted=0", "name",,, /*report_errors*/ true);
I like the concept, a lot :)
Indeed there is the "code written for only this version and above",
from a syntax point of view. But that's something I do not care much
On Wed, Apr 18, 2012 at 1:56 AM, Alexey Shein wrote:
> Hi!
>
> My opinion is that solution tries to overcome bad consequences of
> legacy code, when it's not feasible to change something without
> breakage a lot of code, although the real solution is to refactor
> functions with long variable lis
Hi,
2012/4/18 Ryan McCue :
> Yasuo Ohgaki wrote:
>>
>> Something like
>>
>> setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
>>
>> is really nice to have. Source code will be much more readable.
>
>
> This is getting off-topic, but while we're here, I think:
>
> setcookie($na
On 18 April 2012 01:23, Jordi Boggiano wrote:
> On 18.04.2012 00:54, Stas Malyshev wrote:
>> https://wiki.php.net/rfc/skipparams
>>
>> Basically, it allows you to do this:
>>
>> create_query("deleted=0", "name",,, /*report_errors*/ true);
+1
> - Would it be possible to allow trailing commas in
Yasuo Ohgaki wrote:
Something like
setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
is really nice to have. Source code will be much more readable.
This is getting off-topic, but while we're here, I think:
setcookie($name => 'mycookie', $value => 'abc');
...would be be
Hi,
2012/4/18 Ferenc Kovacs :
> I would prefer Named parameters, but this is still better than the current
> situation.
Something like
setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
is really nice to have. Source code will be much more readable.
Regards,
--
Yasuo Ohgak
On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev wrote:
> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named
On 18 April 2012 06:54, Stas Malyshev wrote:
> create_query("deleted=0", "name",,, /*report_errors*/ true);
I like it. At the risk of bikeshedding, can we have a token rather
than just a series of commas — say reusing the default keyword so it
would look like this instead:
create_query("deleted=
18 апреля 2012 г. 11:40 пользователь Stas Malyshev
написал:
> Hi!
>
>> NULL or empty string? I.e. will optional parameters always get NULLs
>> or their default values?
>
> Their default values. That's the whole point of it - if I wanted just
> nulls, I could put nulls in the call, but if I want th
Hi!
> NULL or empty string? I.e. will optional parameters always get NULLs
> or their default values?
Their default values. That's the whole point of it - if I wanted just
nulls, I could put nulls in the call, but if I want the actual default,
I'd have to find the definition and copy-paste from t
On 18 April 2012 07:56, Alexey Shein wrote:
*snip*
>
> One question about implementation:
> Given we have this function
>> function create_query($where, $order_by, $join_type='', $execute = false,
>> $report_errors = true) {}
> and this statement
>> On the engine level, it will be implemented
Hi!
My opinion is that solution tries to overcome bad consequences of
legacy code, when it's not feasible to change something without
breakage a lot of code, although the real solution is to refactor
functions with long variable lists (as Uncle Bob says), maybe this
should be noted in documentatio
On Tue, Apr 17, 2012 at 6:54 PM, Stas Malyshev wrote:
> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named
Hi!
> a) it kind of encourages using long lists of arguments (which is not
> normally regarded as good practice)
This ship has sailed long ago, these lists are the reality. And
rewriting all the code to change all function calls is in most cases
completely infeasible.
> c) the current situation
On Wednesday, April 18, 2012 06:54 AM, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/skipparams
Basically, it allows you to do this:
create_query("deleted=0", "name",,, /*report_errors*/ true);
Implementation of it is here:
https://github.com/smalyshev/php-src/tree/skip_params
All things
Hi,
2012/4/18 Stas Malyshev :
> Hi!
>
>> Since func_num_args() won't be able to be used to see if an argument is set,
>> could a func_isset_arg() be added? So something like:
>> if(func_num_args() > 2) $value = func_get_arg(2);
>> would become:
>> if(func_isset_arg(2)) $value = func_get_arg(2);
>
Hi!
>> BTW: the diffs show a lot of WS changes that you should probably fix.
That's Eclipse, it loves to strip trailing whitespace... Which btw shows
for some reason we have lots of it in our code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 22
On Wed, Apr 18, 2012 at 2:03 AM, Etienne Kneuss wrote:
> Hi,
>
>
> On Wed, Apr 18, 2012 at 01:56, Stas Malyshev wrote:
>> Hi!
>>
>>> Since func_num_args() won't be able to be used to see if an argument is
>>> set, could a func_isset_arg() be added? So something like:
>>> if(func_num_args() > 2)
Hi,
On Wed, Apr 18, 2012 at 01:56, Stas Malyshev wrote:
> Hi!
>
>> Since func_num_args() won't be able to be used to see if an argument is set,
>> could a func_isset_arg() be added? So something like:
>> if(func_num_args() > 2) $value = func_get_arg(2);
>> would become:
>> if(func_isset_arg(2))
Hi!
> Since func_num_args() won't be able to be used to see if an argument is set,
> could a func_isset_arg() be added? So something like:
> if(func_num_args() > 2) $value = func_get_arg(2);
> would become:
> if(func_isset_arg(2)) $value = func_get_arg(2);
I think it's easier to just do func_get
Hi,
2012/4/18 Simon J Welsh :
> On 18/04/2012, at 10:54 AM, Stas Malyshev wrote:
>
>> Hi!
>>
>> One of the annoying things I've encountered in working with PHP was
>> dealing with functions having long optional parameter lists, especially
>> if you need to change only the last one - you have to co
Hi!
> I'm thinking undefined like JavaScript.
Well, in PHP null is closest, but a bit different. I.e. in JS undefined
a is an error, but a[0] where a is empty is "undefined". In PHP in both
cases you get null and notice, and in both cases you can use isset/empty
to check for it.
--
Stanislav Mal
On 18/04/2012, at 10:54 AM, Stas Malyshev wrote:
> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named para
Hi,
It's undefined, so it does not have to keep track state ;)
But it may require a lot of changes, so I don't matter much.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
2012/4/18 Yasuo Ohgaki :
> Hi,
>
> 2012/4/18 Stas Malyshev :
>> Hi!
>>
>>> Introducing "undefined" might be good.
>>> Intenti
Hi,
2012/4/18 Stas Malyshev :
> Hi!
>
>> Introducing "undefined" might be good.
>> Intention becomes clearer and we may do
>>
>> if ($var === undefined) {
>> echo '$var is undefined';
>> }
>
> What is undefined and how $var gets assigned it?
I'm thinking undefined like JavaScript.
AFAIK, engin
Hi!
> Introducing "undefined" might be good.
> Intention becomes clearer and we may do
>
> if ($var === undefined) {
> echo '$var is undefined';
> }
What is undefined and how $var gets assigned it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext
Hi,
2012/4/18 Stas Malyshev :
> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation wo
On 18.04.2012 00:54, Stas Malyshev wrote:
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation
Stas Malyshev wrote:
Basically, it allows you to do this:
create_query("deleted=0", "name",,, /*report_errors*/ true);
I'm a huge fan of this idea, for all the reasons listed on the RFC and
one additional one: it brings normal functions in line with the syntax
for list() - We can skip param
Hi!
One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists, especially
if you need to change only the last one - you have to copy all the
defaults. Full named params implementation would solve it, probably, but
before we have
59 matches
Mail list logo
