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. 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. > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
