Often my functions accepts an array of options to drive its behavior:
function foo( $data, $options = array() ) {
if ( $options['filter'] = 'int' ) return intval($data);
return $data;
}
The plus of accepting an array of options is your method can grow up without change it’s params API.
I often allow to accepts more than array type for my $options param:
function foo( $data, $options = array() ) {
if ( is_string($options) ) $options = array( 'filter'=>$options );
...
}
This way my method API should be something like:
// full api
echo foo( $data, array('filter'=>'int'));
// compact api
echo foo( $data, 'int' );
I like DRY code so much!
Make it easy!
What PowerSet::def() does is to simplify the logic that convert different $options types into specific property names:
function foo( $data, $options = array() ) {
$options = PowerSet::def($options, null, array(
'string'=>'filter',
'integer'=>'length'
));
...
}
This code should be translated into:
"if $options type is -string- then put it value into -filter- key"
"if $options type is -integer- then put it value into -length- key"
In every cake $options will be converted into an array.
PowerSet::def('aaa', null, 'class');
-> array( 'class'=>'aaa' );
PowerSet::def(24, null, 'length');
-> array( 'length'=> (int) 24 );
PowerSet::def('aaa', null, array( 'string'=>'class', 'integer'=>'length'));
-> array( 'class'=>'aaa' );
PowerSet::def(24, null, array( 'string'=>'class', 'integer'=>'length'));
-> array( 'length'=> (int) 24 );
Why “null” as second param?
You can set up a default array to be extended with given values:
// useful to apply default values to an array
PowerSet::def('container', array(
'id => '',
'class => '',
'style => '',
), 'class');






