Hi all,
I just wish to comment briefly on the null values issue. I think it is
reasonable to expect that there could be valid parameters for which
there exist null values.
In PHP, for a hopefully relevant example, the difference between
array_key_exists() and isset() is that:
* array_key_exists() returns true when the key exists, even if the value
is null
* isset() returns false when the key exists but the value is null
Thus, I believe that the most appropriate method to add for functional
completeness would be:
boolean paramExists($name); // psuedo-signature, of course ;)
Consider also that it might make sense to have getParam($name) throw an
exception if an internal call to paramExists($name) returns false,
though I'm unsure about this assertion. I really don't think it makes
sense for getParam($name) to return null when the value of the parameter
is null AND when the parameter does not exist. Depending on other
considerations, however, I could be convinced otherwise if there is no
better "middle ground."
This method would act the same as array_key_exists(), so that it returns
true whenever the parameter exists, even if the value is null.
Best regards,
Darby
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.
>
