Hi!

I am not sure whether this is a little overhead.

but if we do want this. to be honest, I even prefer leave it empty to
"default".

like create_query("delete=0", "name", , , true);

That's how it was initially, and I was convinced default is better. So I
don't think I'm going back to empty. default indeed seems to be more
readable (try to visually distinguish between ,,,, and ,,,, - if you
have a lot of code, it won't be that easy). It is more verbose, but PHP
never attempted to be "save the bytes" language.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--

Hi,

For me as a user it would make much more sense to have named
parameters then typing default. Default also feels a bit strange to
type. What if I miss one default in the line? Or in the other proposal
here, what if I miss one comma?

Named parameters would also solve a problem from another RFC that's
being proposed right now if I understand correctly so why not go for
that?

Kind regards

Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

On Mon, Sep 2, 2013 at 9:41 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

I am not sure whether this is a little overhead.

but if we do want this. to be honest, I even prefer leave it empty to
"default".

like create_query("delete=0", "name", , , true);

That's how it was initially, and I was convinced default is better. So I
don't think I'm going back to empty. default indeed seems to be more
readable (try to visually distinguish between ,,,, and ,,,, - if you
have a lot of code, it won't be that easy). It is more verbose, but PHP
never attempted to be "save the bytes" language.

another small advantage would be that IDEs could show you the default value
for the argument when hovering the default keyword.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Mon, Sep 2, 2013 at 2:11 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

I think this doesn't really help readability. Right now you should
implement functions with many options with an $options array.

I don't understand. Who says I should do that? I certainly don't see how
I should.

If we want to change something here, we should skip this step and go
right for named arguments. I think I'll give implementing them a try.

If you are ready to present named args proposal for 5.6, fine. But if
not, I think denying obviously requested feature (see links for requests
in the RFC) because some "pie in the sky" consideration is completely
wrong.

I must say it seems a little strange for me given current stream of
"because we can" syntax additions proposed to reject something that has
been asked for by real people for years just because sometime in the
future we might or might not have something that may do a similar thing
in different way.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hi Stanislav

I would not agree with your argument that it should be introduced because it
is requested by real people for years and it is simple to add. Isn't that
pretty much the same as "because we can"?
IMO we should wait with this RFC if Nikita is willing to write an RFC for
named parameters including an implementation afterwards, because I think
named parameters would address the problem way better. The skipping
parameters as in your proposal would then just be the ugly alternative.
However, if the RFC for named parameters will not be created or rejected,
then I would appreciate your RFC.

Best,
Robert

-----Ursprüngliche Nachricht-----
Von: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Gesendet: Montag, 2. September 2013 22:12
An: Nikita Popov
Cc: PHP Internals
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2

Hi!

I think this doesn't really help readability. Right now you should
implement functions with many options with an $options array.

I don't understand. Who says I should do that? I certainly don't see how I
should.

If we want to change something here, we should skip this step and go
right for named arguments. I think I'll give implementing them a try.

If you are ready to present named args proposal for 5.6, fine. But if not, I
think denying obviously requested feature (see links for requests in the
RFC) because some "pie in the sky" consideration is completely wrong.

I must say it seems a little strange for me given current stream of "because
we can" syntax additions proposed to reject something that has been asked
for by real people for years just because sometime in the future we might or
might not have something that may do a similar thing in different way.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
To unsubscribe, visit:
http://www.php.net/unsub.php

I must say it seems a little strange for me given current stream of
"because we can" syntax additions proposed to reject something that has
been asked for by real people for years just because sometime in the
future we might or might not have something that may do a similar thing
in different way.

I would not agree with your argument that it should be introduced
because it
is requested by real people for years and it is simple to add. Isn't that
pretty much the same as "because we can"?

No, it is pretty much the opposite. It is "because people need it".

lolwut, you're kidding right? So you listed a bunch of StackOverflow
questions asking for this and from this concluded that this is a feature
"people need" whereas the RFCs by ircmaxell/me (whichever you mean) are not
needed and are proposed just "because we can" and are not needed by "real
people"? Would you like RFC's to include detailed chat logs, Twitter
mentions and Reddit conversations as proof that features are wanted by
"real people"?

Nikita

2013/9/2 Pierre Joye pierre.php@gmail.com

Any comments or feedback on the RFCs and the code are welcome,
especially pointing out the cases where it may not work (which means
we need more phpt's there :)

Using default instead of ,,, is indeed much more readable.

However I still wonder what prevents to finally implement named
parameters too, it will provide the same feature while being even more
handy and easier.

And it covers an additional use-case: Self-explaning parameters like in
"foo(is_strict = false)" instead of "foo(null, null, false)".

Lots of overlap between variadic functions, this proposal & named parameters.

A popular use case for library authors is to use:

interface foo {
function formatUseCases(array $options);
}

• Advantage: No dependency on a class / object
• Disadvantage: doesn't document what options are available, hard to extend 'default parameters'

interface foo {
function formatUseCases(MyOptions $options);
}

• Advantage: documents which options are available, easy to extend default parameters
• Disadvantage: modification of the object means these 'options' are available to any declaration using it, hard to maintain over time without big refactoring (lots of options objects)

interface foo {
function formatUseCases(...$options);
}

• Advantage: No dependency on a class / object
• Disadvantage: doesn't document what options are available, no default parameters

interface foo {
function formatUseCases($showGood = true, $showBad = true, $pretty = true, $title= "what are these parameters?");
}

• Advantage: Self-documenting with default parameters

• Disadvantage: Not extendable api signature (changing default parameters)

• Readability:

array

formatUseCases(['showGood': true, 'showBad': true, 'pretty': true]);

#object
$obj->showGood = true;
$obj->showBad = true;
$obj->pretty = true;
formatUseCases($obj);

variadic or function declaration

formatUseCases(true, true, true, "what are these parameters?");

• Solution somewhat as a hybrid?
  interface foo {
  function formatUseCases(...$options[showGood = true, showBad = true, pretty = true, title= "what are these parameters?"]);
  }

formatUseCases(true, true, true, "use defaults for everything else");
formatUseCases(['title': "use defaults for everything else"]); // more readable

Implemention wise $options could be ~ SplParameters which implements ArrayInterface :

class bar implements foo {
function formatUseCases(...$options[]) { // api signature as $options[] always accepted (uses default params)
echo get_class($options); // SplParameters
var_dump($options['showGood']) // true;
var_dump($options->showGood) // true;
}
}

class bar2 implements foo {
function formatUseCases(...$options[showGood = false]) { // easy to extend default options
var_dump($options['showGood']) // false;
}
}

Why use special syntax ~ "...$options[]" instead of just named parameters:
http://msdn.microsoft.com/en-us/library/dd264739.aspx

My hunch is that applying named parameters to every function would be very costly in PHP. But as a special syntax applied to a few functions, this might work well.

On Mon, Sep 2, 2013 at 10:19 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

However I still wonder what prevents to finally implement named
parameters too, it will provide the same feature while being even more

For named params, you need to rewrite all args handling, since now it is
a positional array and that doesn't work with named args. On the way
you'd have to refactor zend_parse_parameters to understand named args
(which aren't even named in many internals, so you'd have to add those)
and deal with functions that use + and * in various creative ways and
see how those can be reconciled with named params. And then of course is
the question of by-ref parameters and how to make the syntax handle
those too. Long story short, you'll have to rewrite everything that does
with argument passing, argument receiving or even peeks into arguments.

I already have a mostly-working implementation for named arguments and
unless I missed something critical it does not require us to redo argument
passing. The idea I followed was to keep the argument passing pretty much
as-is, just instead of always pushing on top of the stack to place named
args directly at the correct offsets. So we still have a stack of
positional arguments, they're just inserted out of order. This will also
leave NULL values in between, so they need to be handled as in your
implementation. The only thing you can't handle this way are named
arguments that are not defined in the signature - if we want something like
pythons **kwargs those need to be collected in an HT. I'd likely not
support that at first, land basic named args instead and then seek to merge
kwargs into the RFC's for variadics/unpacking.

Nikita

Am 14.01.2015 um 20:21 schrieb Adam Harvey:

But I think adding "default" as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.

OMG you are right - my fault

I personally also don't like it and asked myself why can't the parameter
simply skipped?
That was in the original proposal, but counting commas is pretty lousy
if you're skipping more than one or two parameters. Having a keyword
makes it more readable.

Adam

Marc Bennewitz, Stas,

But I think adding "default" as new keyword is a big BC break!
I personally also don't like it and asked myself why can't the parameter
simply skipped?

Default is already a reserved word AFAIK. But I've been thinking about
alternatives to parameter skipping syntax which brought me the Golang
blank identifier _ to mind:

create_query("deleted=0", "name", _, _, true);

Still not sure if it's better than default, though.

That would be a BC break as you can currently have a constant _. An existing keyword makes upgrading easier, and default is easier to understand by someone who doesn’t know about the feature than an underscore.

Simon Welsh
Admin of http://91carriage.com/ – Specialised SilverStripe hosting

Hi!

It's not part of the original proposal, and I'm not sure how easy it
would be to implement, but it sounds like a nice extension, I didn't
think about it. Since the RFC is already in vote, I won't change it now,

Strike that, I was confused, for some reason I thought I've already put
it to vote, even though I've put to vote my other RFC (shameless plug:
https://wiki.php.net/rfc/default_ctor, go there and vote Yes ;). Too
many RFCs :) So I'll think if it's easy to add and maybe add it before
it goes to vote.

--
Stas Malyshev
smalyshev@gmail.com

Hi Stas,

-----Ursprüngliche Nachricht-----
Von: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Gesendet: Mittwoch, 14. Januar 2015 21:26
An: Marc Bennewitz; internals@lists.php.net
Betreff: Re: [PHP-DEV] [RFC] Skipping parameters take 2

Hi!

Is it possible to use the default parameter on inheritance?

class Bar {
function foo($a='a', $b='b') {}
}

class Baz extends Bar {
function foo($a=default, $b=default) {
// do something
parent::foo($a, $b);
}
}

It's not part of the original proposal, and I'm not sure how easy it would be to implement, but it sounds like a nice
extension, I didn't think about it. Since the RFC is already in vote, I won't change it now, but I'll look into if
it's possible to do
it, and if the RFC is accepted, and it proves possible, I'll propose it separately.

--
Stas Malyshev
smalyshev@gmail.com

This would be quite a nice feature, even if this RFC does not pass. Just as hint, there are ambiguous case which need to
be considered:

interface A{
function foo($a=1);
}
interface B{
function foo($a="hi");
}
class C implements A, B{
function foo($a=default){} //what would be the default value?
}

Cheers,
Robert