Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender)
To: PHP Internals <internals@lists.php.net>
Date: Mon, 2 Sep 2013 17:47:36 -0700
Thread-Topic: [PHP-DEV] [RFC] Skipping parameters take 2
Thread-Index: Ac6oPy6O/RvCnz0qToO+7CZAU8OfhA==
Message-ID: <80742DA8-3947-4569-8643-4075FF213259@newtekemail.com>
References: <52243BA6.5040905@sugarcrm.com>
 <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
 <5224F2EC.2090609@sugarcrm.com>
 <CAF+90c_1XyHP9+-fJUm7uTg_DH_tfa3yZc-wkGThKDxiYY5eFw@mail.gmail.com>
 <52250A97.8050406@sugarcrm.com>
 <CAF+90c8CXPxVuORfivyJ9EVZny6Ywzm_3rOs+q0kUPJ=VjB6Yg@mail.gmail.com>
 <52251149.4080308@sugarcrm.com> <522517D5.7020603@lsces.co.uk>
In-Reply-To: <522517D5.7020603@lsces.co.uk>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: 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: rewilliams@thesba.com (Robert Williams)

On Sep 2, 2013, at 15:54, "Lester Caine" <lester@lsces.co.uk> wrote:

> Parameter hashes are what we have been converting everything TO because i=
t was
> supposed to be the 'proper way to do it' a few years back.

If you have lots of parameters to pass in, the better solution is to use an=
 object, which lets you formally define what is required to be passed in. T=
he parameter hash, or the parameter block as it was known in decades past, =
is a compromise solution that was widely used before OOP really caught on. =
In this context, it is essentially the same thing as a simple object but wi=
thout the formal definition.

The lack of formal definition is what makes it a terrible idea because it o=
bfuscates the parameters of the function. If you hand off the code to someo=
ne else to use, they must to look at the implementation to see how it works=
 to figure out what to pass in. Oh, there may be separate docs, but they ca=
n't be auto-generated, and we all know how well code docs are kept up-to-da=
te when they're not auto-generated. Plus, PHPDoc doesn't support parameter =
blocks, which means that IDEs can't offer the same level of assistance with=
 code-completion that they offer for both objects and straight parameters -=
- another huge downside.

Parameters were invented as an abstraction around passing raw, untyped and =
unnamed stacks of data. Parameter blocks take us back to that.

Back to the topic, I like what Stas has proposed. Further, I don't see name=
d parameters as replacing the utility of default parameters. For long param=
eter lists, named parameters would usually make more sense to use, I think,=
 but for medium lists, I think the default keyword is much cleaner because =
it doesn't require doubling or tripling the length of what you type for the=
 parameter list to ensure you're getting the default value for a parameter.=
 And where named parameters are overkill, it keeps the focus of anyone read=
ing the code firmly on the values, not the parameter names. In other words,=
 the two features complement each other, with one or the other being better=
 in different contexts.

I don't get a vote, but if I did, I'd say implement what Stas has put forth=
, and if named parameters can come into the picture at some point, implemen=
t that, too.


--
Bob Williams

Notice: This communication, including attachments, may contain information =
that is confidential. It constitutes non-public information intended to be =
conveyed only to the designated recipient(s). If the reader or recipient of=
 this communication is not the intended recipient, an employee or agent of =
the intended recipient who is responsible for delivering it to the intended=
 recipient, or if you believe that you have received this communication in =
error, please notify the sender immediately by return e-mail and promptly d=
elete this e-mail, including attachments without reading or saving them in =
any manner. The unauthorized use, dissemination, distribution, or reproduct=
ion of this e-mail, including attachments, is prohibited and may be unlawfu=
l. If you have received this email in error, please notify us immediately b=
y e-mail or telephone and delete the e-mail and the attachments (if any).