Re: [RFC] Skipping parameters take 2

From: Date: Tue, 03 Sep 2013 00:47:36 +0000
Subject: Re: [RFC] Skipping parameters take 2
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Sep 2, 2013, at 15:54, "Lester Caine" <[email protected]> wrote:

> Parameter hashes are what we have been converting everything TO because it 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. The 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 without the formal
definition.

The lack of formal definition is what makes it a terrible idea because it obfuscates the parameters
of the function. If you hand off the code to someone 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 can't be auto-generated, and we all know how well code docs are kept up-to-date 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 named parameters as
replacing the utility of default parameters. For long parameter 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 reading 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, implement 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 delete this e-mail, including attachments without reading or saving them
in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail,
including attachments, is prohibited and may be unlawful. If you have received this email in error,
please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if
any).


Thread (69 messages)

« previous php.internals (#68879) next »