-- Matthew Ratzloff <[email protected]> wrote (on Saturday, 17 January 2009, 12:14 PM -0800): > Since configuration is such a fundamental aspect of most components, perhaps > this can be added to the coding standards, along with whatever suggested > implementations the community agrees upon?
I've actually been planning on reviewing the CS and proposing changes such as this for some months now; just waiting for it to move up in priority in my backlog. > On Sat, Jan 17, 2009 at 6:55 AM, Matthew Weier O'Phinney <[email protected]> > wrote: > > -- 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/ > > -- Matthew Weier O'Phinney Software Architect | [email protected] Zend Framework | http://framework.zend.com/
