-- Matthew Ratzloff <[email protected]> wrote (on Friday, 16 January 2009, 09:42 AM -0800): > This is more or less how you see the setOptions() implementation in a few > > classes currently. The idea that you proxy the key to a mutator (setter) > > setSomething($value) method. > > > Yep, except it's in one place instead of several with tiny variations. And it > works with static setters.
But your solution would introduce a hard dependency on another class. One principle we have espoused from the beginning is that we would not have a "base" class used by all other classes, in an effort to reduce dependencies. There's also good reasons to implement setOptions functionality on a class-by-class basis. One is to allow for class-specific behavior; for instance, one class might discard unknown keys, another might set them as class metadata. Another implementation might proxy to protected methods. Another implementation might make setOptions protected so that the class can be used within a service. In other words, the variations in _behavior_ have their purpose. But the constructors would still have the same public API -- leaving a consistent _use case_ that can be messaged. > On Fri, Jan 16, 2009 at 9:12 AM, Ralph Schindler <[email protected]> > wrote: > > > > The primary problem with configuration in Zend Framework is that > configuration > > is left up to each class and so each class handles it differently. The > > primary problem with PHP is lack of mixins, which would elegantly solve > the > > first problem. I solved the issue at my job like this: > > > The initial problem is that each class solves the configuration without > any > regard to how other components solve the configuration issue (the common > convention). This thus creates a somewhat ambiguous API. I think one of > the stories I'd like to see told with ZF2 is more one of API consistency, > fewer statics, and those statics that are used are part of an acceptable > list of static usages... All for the purpose of keeping things consistent. > > > > public static function setConfig($caller, $config, $section = null) > > { > > $config = self::getOptionsFromConfig($config, $section); > > > > foreach ($config as $option => $value) { > > $method = 'set' . ucfirst($option); > > > > if (method_exists($caller, $method)) { > > if ($value instanceof Zend_Config) { > > $value = $value->toArray(); > > } > > > > if (is_object($caller)) { > > $caller->$method($value); > > } else { > > call_user_func(array($caller, $method), $value); > > } > > } > > } > > > > return $config; > > } > > > This is more or less how you see the setOptions() implementation in a few > classes currently. The idea that you proxy the key to a mutator (setter) > setSomething($value) method. > > > > This is a pretty flexible approach that allows instance or static method > calls > > on the caller and does not distinguish between Zend_Config objects and > arrays. > > In my experience there is no practical benefit, and some drawbacks, to > > distinguishing between separate setConfig() and setOptions() methods. > If > you > > must store the configuration in the object, for example to allow a > generic > > getOption($optionName) method, the logic is still off-loaded to the > other > > class. > > > > > The major difference I think Matthew W.O. Was trying to demonstrate is > that > those methods have different signatures: > > Public function setConfig(Zend_Config $config); > Public function setOptions(Array $options); > > This creates a very loose coupling on Zend_Config for instances where one > would like to use Zend_Config. In other cases, an associative array is > just > fine. > > -ralph > > -- > Ralph Schindler > Software Engineer | [email protected] > Zend Framework | http://framework.zend.com/ > > -- Matthew Weier O'Phinney Software Architect | [email protected] Zend Framework | http://framework.zend.com/
