In principle I agree with Gerrit regarding "null is a perfectly valid
value", but only as a programmatic idiom, while the semantic meaning of
null normally centers on "the absence of a value". Null "values" are
commonly used as the "value" of a key or field in a DB, but there are
simple ways to distinguish between a key or DB row having a null value,
and the absence of the key or field (i.e. row does not exist in DB).
When null values are taken alone, by themselves, ambiguity arises, if
they are used to denote the absence of a value and anything else.
However, if we support setting null values, and clearParam(), then we
probably need isSet(). The existing approach allows for simpler
userland code, than directly supporting null values in parameters.
I suggest we elevate this issue to a coding standard discussion, or at
least develop a "best practices" recommendation for the ZF. How should
components with getter methods represent the absence of values?
- return null (as currently done)
- return an global NULL object (languages with both a NULL object and a
built-in type of null avoid the difficulty Gerrit highlighted)
- return false
- return an empty string (similar to a DB query)
- return a 2-tuple, where the second value denotes the type of the first
(e.g. [null, false], where false indicates the absence of a value)
- throw an error (j/k)
- don't distinguish between null values and the absence of a value (i.e.
rely on an additional isNull() method)
- ?
Cheers,
Gavin
Matthew Weier O'Phinney wrote:
-- Gerrit Thomson <[EMAIL PROTECTED]> wrote
(on Saturday, 11 November 2006, 12:03 AM +1100):
Why unset it once it is set? null is a perfectly valid value to set
something to. If you want the ability to unset something implement it.
Side effects like the one you describe will catch more than one person
out. if not in this class then in others where this code style is
taken as a template.
getParam() returns null both for null values as well as when the value
does not exist in the param stack. The only place this would be an issue
is when calling getParams(); under the current code, the array key would
exist, pointing to a null value, but under the proposed code, the
element would not exist.
I can see an argument for clearParam($name), but it seems a bit
redundant. I'll think on it more today before making any changes.
Remember all the code of the framework has to conform to the coding
style of the framework. The framework will be taken as a code style
guide and a code template. I am not sure about the coding style with
regards to return parameters. Has it been decided to return "this" if
nothing is expected? If nothing is expected then why would I expect to
receive "this"?
I think you're referring to the fluid interfaces introduced in the MVC
rewrite with regards to the set*() methods.
The decision to do this was to make object configuration easy and
readable, and to reduce the amount of typing necessary. Under the old
code, you'd have something like this to setup your front controller:
$front->setDispatcher($dispatcher);
$front->setRouter($router);
$front->setControllerDirectory('../controllers');
Contrast this with fluid interfaces:
$front->setDispatcher($dispatcher)
->setRouter($router)
->setControllerDirectory('../controllers')
->setParam('view', $view)
->setParam('registry', $registry);
This type of interface is used in a number of places in the framework,
and reduces redundant typing considerably. It is only used in places
where no return value is expected and where the method call is simply
being used to set object state.
On 10/11/06, Simon Mundy <[EMAIL PROTECTED]> wrote:
Sounds great Matthew, cheers!
-- Simon Mundy < [EMAIL PROTECTED]> wrote
(on Friday, 10 November 2006, 09:12 AM +1100):
I noticed that the latest commit to the dispatcher has 'setParam' and
'clearParam'. Would it be possible to supply a string or an array of
strings to 'clearParam' to selectively unset them as well as the
option to clear all?
clearParams() is intended to clear the entire parameter stack.
setParam($name, null) would clear a single value, though the array key
would still exist; I'll modify the code to unset if a null value is
passed.
