Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68853
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gdesolutions.com designates 207.46.163.204 as permitted sender)
To: Sebastian Krebs <krebs.seb@gmail.com>, Pierre Joye <pierre.php@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Skipping parameters take 2
Thread-Index: AQHOp6yM4alq4mUdOECKJoiZumCmoZmyYZEAgAAFtQCAACKI8A==
Sender: Jonathan Bond-Caron <jbondc@gdesolutions.com>
Date: Mon, 2 Sep 2013 16:04:11 +0000
Message-ID: <d55e23b62c2a449991780c729a4488f3@BN1PR07MB135.namprd07.prod.outlook.com>
References: <52243BA6.5040905@sugarcrm.com>
 <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
 <CALtuQzBZ=xGK0Ra+L_1VS9tgptjbUpcU4kYESdpfOaNq5eLvcA@mail.gmail.com>
In-Reply-To: <CALtuQzBZ=xGK0Ra+L_1VS9tgptjbUpcU4kYESdpfOaNq5eLvcA@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] Skipping parameters take 2
From: jbondc@openmv.com ("jbondc@openmv.com")

On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> 2013/9/2 Pierre Joye <pierre.php@gmail.com>
>=20
> > >
> > > 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.
>=20
>=20
> And it covers an additional use-case: Self-explaning parameters like in
> "foo(is_strict =3D false)" instead of "foo(null, null, false)".
>=20
>=20

Lots of overlap between variadic functions, this proposal & named parameter=
s.

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 availa=
ble to any declaration using it, hard to maintain over time without big ref=
actoring (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 par=
ameters

interface foo {
  function formatUseCases($showGood =3D true, $showBad =3D true, $pretty =
=3D true, $title=3D "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 =3D true;
$obj->showBad =3D true;
$obj->pretty =3D 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 =3D true, showBad =3D true, =
pretty =3D true, title=3D "what are these parameters?"]);
}

formatUseCases(true, true, true, "use defaults for everything else");
formatUseCases(['title': "use defaults for everything else"]); // more read=
able

Implemention wise $options could be ~ SplParameters which implements ArrayI=
nterface :

class bar implements foo {
  function formatUseCases(...$options[]) { // api signature as $options[] a=
lways 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 =3D false]) { // easy to ext=
end 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 mig=
ht work well.