Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49950
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        b=Id5uMxgLdHtTFBw/DE7LGVlKIBay2eRPuUUgeOoB7ccH8YNHt0EkDaTAfqGPojXrFI
         MwbFDkBkrDzrhhXviBk9m/P+yDIXFFokrFbi8TW11a9pD6t92fgpcJx7rNPcIcVE78eJ
         Luw0lxn8nCUZO+XyIcnaGVp1O9219CgQKejZw=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <A845D19B813D4FC58BE82E90894D70F9@pc>
References: <AANLkTi=VerH9yhv7+sSyvbzNp3fmkW+NFvvc2zgEu5Av@mail.gmail.com>
 <988651dd53129fdfd1acb905c8161e95.squirrel@www.l-i-e.com> <A845D19B813D4FC58BE82E90894D70F9@pc>
Date: Thu, 21 Oct 2010 11:37:55 +0100
Message-ID: <AANLkTimEs--8MP0dD2uMwqdN-1dGmXGj0Yw=-tKB=k8K@mail.gmail.com>
To: Stan Vass <sv_forums@fmethod.com>
Cc: Richard Lynch <ceo@l-i-e.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Skipping of defaulted parameters.
From: rquadling@gmail.com (Richard Quadling)

On 21 October 2010 09:11, Stan Vass <sv_forums@fmethod.com> wrote:
>>> Option 4 would probably be the worse one to go for. Looking any number
>>> of languages that support defaults and you will see code like ...
>>>
>>> someFunction(param1,,,,,param7,,,,param11)
>>
>> It does get ugly fast for large numbers of arguments...
>> But any function with more than a handful of arguments is already
>> asking for trouble...
>>
>> At that point you should be passing in a data structure / instance /
>> array or something other than so many parameters.
>>
>
> The above example would have at least 10 arguments, so I'd also say it'd
> look bad never mind the syntax.
>
> Also a subtle thing: if your email reader doesn't use fixed width font, it's
> hard to appreciate the look of each approach in an actual code editor.
> And I'd say commas next to each other appear quite readable, self-sufficient
> in fixed-width font, not to mention self-explanatory.
>
> Using 'default' would raise more confusion, such as, is that valid: $foo =
> default; bar($foo);
> If it's made valid, i.e. if it acts as a constant, I suspect before long
> people will be assigning 'default' as yet another alternative to a
> false/null value, and we'll need yet another concept to resolve that.
> If it's not made valid, it'll be counter-intuitive as it looks exactly like
> a constant passed as an argument.
>
> Stan Vass


I'm not only talking about userland code here.

There are MANY functions in PHP that utilise default parameters.

In most cases the lesser used parameters are at the end of the
parameter list and it more often than not, it makes sense to supply
the preceding parameters.


Yes, I know a bunch of commas, one after the other, is unreadable.
I've seen VBA code!


I want null to be null. Not to be interpreted as a value. If I pass a
null to a function with a default, I'm specifically NOT setting the
value. Null has no value. The default is the only option that should
be used.

This can only apply to scalars. Objects, resources and arrays should
all have the =null option.


I'm guessing that the issue with implementing this in core is that
each function is responsible for the defaults in such a way that they
cannot easily be abstracted to the parameter processing code.

The parameter values are first set to their defaults and then
overwritten by the parameter processing code.

I think that, for scalars, if I've supplied null, there is no value to
overwrite.

Take this example. This is the first function in the manual that has
an optional parameter.

int apc_bin_dumpfile ( array $files , array $user_vars , string
$filename [, int $flags [, resource $context ]] )

Arguments that have been raised about too many parameters ... how many
is too many? Is 5 OK? Why not x?

$flags has no default here, but it is an int, so I have to assign
something (well, I don't the default is 0 and the documentation is out
on this issue, but that's another issue).

So, off I go read the manual to be redirected to another page to get
the list of flags I can 'OR'.

But, assuming the default was documented, the prototype would look
more like int $flags = 0

So, I want to use the default. OK. 0 vs null in terms of code, 0 is
shorter, but it means that if the default was to change (not with this
function, but any function - and that could be userland), then
allowing me to say "use whatever the default is" would certainly be
the way to protect me.



-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY