Peter Lind wrote:
On 24 March 2010 16:09, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
Peter Lind wrote:
On 24 March 2010 15:33, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
Peter Lind wrote:
One of the main points of the OP was that you can document the code
properly. Your example doesn't allow for nice docblocks in any way, as
you'll either have to param points or a whole lot of noise.
I dunno, seems highly documentable to me. Each route is handled by it's
own
method with the parameters being fully declared in the handler method's
signature.
Only problem is the OP wanted to be able to created objects with
variable amounts of arguments. I.e. passing just one argument to the
constructor wasn't an option, far as I could tell. That's why he was
looking at c++/c# overloading: creating a constructor for each
scenario because the amount and kind of arguments varied.
Which means that the docblock for your constructor will look something
like
/**
* dynamic constructor
*
* @param int $constructor_type
* @param string|array|object|whatever_you_could_think_to_throw_at_it
$something
* @param string|array|object|whatever_you_could_think_to_throw_at_it
$something this is optional
* @param etc
*
* @access public
* @return void
*/
Actually, I would write it more like the following:
/**
* dynamic constructor that delegates construction and parameters to a
* registered alternate constructor. See specific constructors for
* supported parameters.
*
* @param int $constructor_type
* @param mixed $param,....
*
* @access public
* @return void
*/
The ,... is a supported syntax. Then I'd add the appropriate docblock for
the alternate constructors.
It might be but in effect the documentation you're left with is vague
and has double the amount of documentation lookups, to find out which
parameters you can pass. Using a separate object to create the one you
want avoids this.
But then you need to keep track of many different classes/objects rather
than a single. You also run into confusion as to what the difference is
when really they are the same, just built differently. In this context
you have even more document points to review since you must read the
class information in addition to the method signature. Also using a
separate class just to facilitate a different constructor seems abusive
of class semantics since the objects are intended to be identical, just
built differently. I would find this more unwieldy to deal with in an
environement than just viewing the alternate methods.
However, which solution fits the problem best is determined by the
angle you're looking from. If you want to avoid extra classes, having
a constructor like you're supposing is probably the best idea.
Extra classes is also more code, probably more files (if you put them in
separate files), more points of management.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
