On 24 March 2010 16:23, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > 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. Yes, you have to keep track of two different objects instead of one. Managing complexity by delegating responsibility is normally a good thing. And no, there is no confusion: you're building the same object in different ways, so you're getting the same object, not one that merely looks the same. As for abusing class semantics ... I don't see it. Using separate classes for different things is what OOP is about. If your constructor is trying to do 15 different things you're designing it wrong - methods shouldn't have to rely upon massive switches or the equivalent done using foreach loops and arrays. As for more documentation: You'd have two class docblocks plus a docblock for each build method, so I suppose you're right, that is one extra docblock. >> 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. Yes. What does your code look like? One big file containing everything? > 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
