All posts by

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');