Daniel Macedo wrote:
I am sorry Lester, but you seem to be getting the "optional parameter"
backwards.
You are supposed to use the optional parameters when it's up to the
library/function definition to determine it's value, not when the
value is what you want for this particular function call!
What you seem to be currently reading from a function definition when
using it is i.e.: "This parameter's default is TRUE? That's what I
need it to be here, skip typing it!"
This is the wrong approach for proper design, and you will have a lot
of headaches when refactoring!
If you use them*properly*, what you read when using the function call
is "I don't need/want to change the default value for this optional
parameter, use what the library determines!", this is the proper way
to use a function call with optional parameters, that will give you a
LOT less headaches!
I'm reading things exactly has they are written ...
If I am USING a later optional parameter, then with well written libraries I
also often need to change the earlier optional ones. Since my IDE provides an
overview of how the defaults have been defined I can check, but I *HAVE* been
stung by changes of a default value in the library which then messed up
operation requiring the optional parameter to be set. Adding the ability of also
having to check earlier optional parameters just seems adding to the agro
without any real gain! I'm not talking about MY use of this, but is inclusion
without thought in library code.
The problem with the way things work currently, is that the default
value, is now*hard coded* into all function calls were you wanted to
use the default, but needed to define a latter optional parameter!
Hence the proper use would be to either use a reserved word, or having
named parameters.
I personally think there's a place for having both.
Yet another reason for wanting a LTS version of PHP that we can use without
worrying about all these 'extras'. Named parameters have been discussed in the
past, and not taken forward. If you NEED named parameters, simply use a
parameter hash ... which is the normal practice for 'heavy' parameter passing
anyway.
Similarly if I could trust the library maintainers NOT to change a default, then
'default' might make sense, but to be honest trying to keep libraries working is
as bad nowadays as keeping my own code working as well. I've just finished 3
heavy days making the bulk of the bitweaver code 'strict' safe. Much of the code
still needs extra work, but the bulk of what I USE is now clean. NOW I have to
do the same on the libraries that it uses ... In the absence of a GOOD guide to
'preferred practice' rewriting the bw code to include ALL the public/private
additions will have to wait.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
