In my framework my set methods set a flag to indicate a value has been set and my get methods check the flag and throw an exception if a value has not been set. I also implement isset and unset methods for object attributes ( which are all virtual ).
To my way of thinking is a program ever ties to use a value that has not been set then it an error in the code. I know php is flexible with regards to variable initialisation etc but in the commercial apps I write I cant afford to assume anything so I control everything.
So if the code tries to use a value that isn't there I make sure it fails badly.
Cheers,
Gerrit.
On 11/11/06, Richard Thomas
<[EMAIL PROTECTED]> wrote:
I really think you need an isset method... To confirm to php5 and
estrict type programming I tend to do the following all the time anyway,
if(isset($val) AND $val) {
echo 'do something'
}
To me this structure just makes sense, helps avoid coding errors and in
general really ensures you have predefined your values ahead of time or
they just are not used.
Doing anything else can lead to injection attacks and bad programming.
I think the accessing of a value that does not exist should throw a
warning, and a isset method should always be provided, this will "push"
more structurally correct and safe programming practices.
Richard Thomas - Code Monkey
Cyberlot Technologies Group Inc.
507.398.4124 - Voice
Gavin Vess wrote:
> 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.
>>>>
>
