Heya! Sorry for not replying before. Yes, Zend\Code is not state of the art right now.
I actually think the "long constructors" make sense on generator classes because of their nature (a class generator is basically a structure in Zend\Code). That's much better than a big amorph array of settings. I think it should stay as it is. For ZF3 we can think of separating this "structure" from the actual code generation logic, which would make a lot of sense to me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 4 July 2013 04:26, zionsg [via Zend Framework Community] < [email protected]> wrote: > Was referring to the ZF2 documentation for Zend\Code\Generator: > > http://zf2.readthedocs.org/en/latest/modules/zend.code.generator.examples.html > > All the examples do not work as they were based on ZF1's CodeGenerator. > > All the components of ZF1's CodeGenerator extended an AbstractGenerator > which took in an array of options via the constructor which then passed it > to setOptions. All the extending classes had to do was to create setters > and getters for each option. IMHO, this makes for easy extension and makes > good use of the parent class. > > ZF2's Code Generator is a drastic change. All the components > (FileGenerator, ClassGenerator, DocBlockGenerator, etc) have their own > constructors which took in a different number of arguments and do not > support passing in of an options array anymore. Instead a fromArray method > is written for each class. And the options are "hardcoded" in each > constructor and fromArray method. > > For example, the constructor for ZF2's Zend\Code\Generator\ClassGenerator: > > public function __construct( > $name = null, $namespaceName = null, $flags = null, $extends = > null, > $interfaces = array(), $properties = array(), $methods = array(), > $docBlock = null > ) { > if ($name !== null) { > $this->setName($name); > } > // all the other arguments are covered ... > } > > An excerpt from the fromArray() method: > > switch (strtolower(str_replace(array('.', '-', '_'), '', $name))) { > case 'containingfile': > $cg->setContainingFileGenerator($value); > break; > // all the various options are covered ... > } > > Was there any rationale behind this change? I was thinking of correcting > the docs but hesitated after comparing the source code. One might lose > track of the meaning of the 8 arguments in the constructor above versus an > associative array with descriptive option keys. > > Should there be a rewrite and sent to the develop branch or leave it as it > is? > > Zion Ng > Singapore > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://zend-framework-community.634137.n4.nabble.com/ZF2-Zend-Code-Generator-components-no-longer-take-in-options-array-via-constructor-tp4660523.html > To start a new topic under Zend Framework, email > [email protected] > To unsubscribe from Zend Framework Community, click > here<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=634137&code=b2NyYW1pdXNAZ21haWwuY29tfDYzNDEzN3wxNzE0OTI1MTk4> > . > NAML<http://zend-framework-community.634137.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/ZF2-Zend-Code-Generator-components-no-longer-take-in-options-array-via-constructor-tp4660523p4660576.html Sent from the Zend Framework mailing list archive at Nabble.com.
