Properly handling multiple constructors.

Hi.

I have a scenario where I would _like_ to have multiple constructors
for a class.

Each constructor has a greater number of parameters than the previous one.

e.g.

class myClass {
__construct(string $Key) // use key to get the complex details.
__construct(string $Part1, string $Part2, string $Part3) //
Alternative route to the complex details.
__construct(array $Complex) // All the details
}

Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
and 3 are the main details and well documented defaults for the rest
of the rules. Complex is all the rules.

Each constructor will end up with all the parts being known ($Key,
$Part1, $Part2, $Part3, $Complex).

But, PHP doesn't support multiple constructors.

Initially I thought about this ...

__construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)

But then documenting the first param as being 1 of three different
meanings is pretty much a no go.

So I'm looking for a clean and easily understood way to provide this.

I won't be the only user of the code and not everyone has the same
knowledge level, hence a mechanism that is easily documentable.

I think I may need a factory with multiple methods (FactoryKey,
FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
All these methods eventually call the real class with the complex
rule.

Is that obvious enough?

Regards,

Richard.


--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Hmmm, that looks to me like you're trying to solve a problem in PHP
with a c/c++c/# overloading solution. I'd give the builder pattern a
try instead: http://en.wikipedia.org/wiki/Builder_pattern

On 24 March 2010 13:01, Richard Quadling wrote:
> Hi.
>
> I have a scenario where I would _like_ to have multiple constructors
> for a class.
>
> Each constructor has a greater number of parameters than the previous one.
>
> e.g.
>
> > class myClass {
> __construct(string $Key) // use key to get the complex details.
> __construct(string $Part1, string $Part2, string $Part3) //
> Alternative route to the complex details.
> __construct(array $Complex) // All the details
> }
>
> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
> and 3 are the main details and well documented defaults for the rest
> of the rules. Complex is all the rules.
>
> Each constructor will end up with all the parts being known ($Key,
> $Part1, $Part2, $Part3, $Complex).
>
> But, PHP doesn't support multiple constructors.
>
> Initially I thought about this ...
>
> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>
> But then documenting the first param as being 1 of three different
> meanings is pretty much a no go.
>
> So I'm looking for a clean and easily understood way to provide this.
>
> I won't be the only user of the code and not everyone has the same
> knowledge level, hence a mechanism that is easily documentable.
>
> I think I may need a factory with multiple methods (FactoryKey,
> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
> All these methods eventually call the real class with the complex
> rule.
>
> Is that obvious enough?
>
> Regards,
>
> Richard.
>
>
> --
> -----
> Richard Quadling
> "Standing on the shoulders of some very clever giants!"
> EE : http://www.experts-exchange.com/M_248814.html
> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 03/24/2010 05:31 PM, Richard Quadling wrote:
> Hi.
>
> I have a scenario where I would _like_ to have multiple constructors
> for a class.
>
> Each constructor has a greater number of parameters than the previous one.
>
> e.g.
>
> > class myClass {
> __construct(string $Key) // use key to get the complex details.
> __construct(string $Part1, string $Part2, string $Part3) //
> Alternative route to the complex details.
> __construct(array $Complex) // All the details
> }
>
> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
> and 3 are the main details and well documented defaults for the rest
> of the rules. Complex is all the rules.
>
> Each constructor will end up with all the parts being known ($Key,
> $Part1, $Part2, $Part3, $Complex).
>
> But, PHP doesn't support multiple constructors.
>
> Initially I thought about this ...
>
> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>
> But then documenting the first param as being 1 of three different
> meanings is pretty much a no go.
>
> So I'm looking for a clean and easily understood way to provide this.
>
> I won't be the only user of the code and not everyone has the same
> knowledge level, hence a mechanism that is easily documentable.
>
> I think I may need a factory with multiple methods (FactoryKey,
> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
> All these methods eventually call the real class with the complex
> rule.
>
> Is that obvious enough?
>
> Regards,
>
> Richard.
>
>

Don't give specify any parameters in the function declaration.

Use helper functions inside the class, and decide at the constructor
which helper to call using func_get_arg() and func_get_args()

You can get the no. of arguments using count(func_get_args())

and then using swtich statement call the relevant helper function using
call_user_func_array with parameters.

A sample:

public function __construct() {

switch(count(func_get_args())) {

case 1:
call_user_func_array(array($this, '_helper1'), func_get_args());
break;
// and so on
}

}

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 03/24/2010 05:38 PM, Nilesh Govindarajan wrote:
> On 03/24/2010 05:31 PM, Richard Quadling wrote:
>> Hi.
>>
>> I have a scenario where I would _like_ to have multiple constructors
>> for a class.
>>
>> Each constructor has a greater number of parameters than the previous
>> one.
>>
>> e.g.
>>
>> >> class myClass {
>> __construct(string $Key) // use key to get the complex details.
>> __construct(string $Part1, string $Part2, string $Part3) //
>> Alternative route to the complex details.
>> __construct(array $Complex) // All the details
>> }
>>
>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>> and 3 are the main details and well documented defaults for the rest
>> of the rules. Complex is all the rules.
>>
>> Each constructor will end up with all the parts being known ($Key,
>> $Part1, $Part2, $Part3, $Complex).
>>
>> But, PHP doesn't support multiple constructors.
>>
>> Initially I thought about this ...
>>
>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>
>> But then documenting the first param as being 1 of three different
>> meanings is pretty much a no go.
>>
>> So I'm looking for a clean and easily understood way to provide this.
>>
>> I won't be the only user of the code and not everyone has the same
>> knowledge level, hence a mechanism that is easily documentable.
>>
>> I think I may need a factory with multiple methods (FactoryKey,
>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>> All these methods eventually call the real class with the complex
>> rule.
>>
>> Is that obvious enough?
>>
>> Regards,
>>
>> Richard.
>>
>>
>
> Don't give specify any parameters in the function declaration.
>
> Use helper functions inside the class, and decide at the constructor
> which helper to call using func_get_arg() and func_get_args()
>
> You can get the no. of arguments using count(func_get_args())
>
> and then using swtich statement call the relevant helper function using
> call_user_func_array with parameters.
>
> A sample:
>
> public function __construct() {
>
> switch(count(func_get_args())) {
>
> case 1:
> call_user_func_array(array($this, '_helper1'), func_get_args());
> break;
> // and so on
> }
>
> }
>

Oops, I missed func_num_args().

Use func_num_args() instead of that count expression.

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 12:08, Nilesh Govindarajan wrote:
> On 03/24/2010 05:31 PM, Richard Quadling wrote:
>>
>> Hi.
>>
>> I have a scenario where I would _like_ to have multiple constructors
>> for a class.
>>
>> Each constructor has a greater number of parameters than the previous one.
>>
>> e.g.
>>
>> >> class myClass {
>> __construct(string $Key) // use key to get the complex details.
>> __construct(string $Part1, string $Part2, string $Part3) //
>> Alternative route to the complex details.
>> __construct(array $Complex) // All the details
>> }
>>
>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>> and 3 are the main details and well documented defaults for the rest
>> of the rules. Complex is all the rules.
>>
>> Each constructor will end up with all the parts being known ($Key,
>> $Part1, $Part2, $Part3, $Complex).
>>
>> But, PHP doesn't support multiple constructors.
>>
>> Initially I thought about this ...
>>
>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>
>> But then documenting the first param as being 1 of three different
>> meanings is pretty much a no go.
>>
>> So I'm looking for a clean and easily understood way to provide this.
>>
>> I won't be the only user of the code and not everyone has the same
>> knowledge level, hence a mechanism that is easily documentable.
>>
>> I think I may need a factory with multiple methods (FactoryKey,
>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>> All these methods eventually call the real class with the complex
>> rule.
>>
>> Is that obvious enough?
>>
>> Regards,
>>
>> Richard.
>>
>>
>
> Don't give specify any parameters in the function declaration.
>
> Use helper functions inside the class, and decide at the constructor which
> helper to call using func_get_arg() and func_get_args()
>
> You can get the no. of arguments using count(func_get_args())
>
> and then using swtich statement call the relevant helper function using
> call_user_func_array with parameters.
>
> A sample:
>
> public function __construct() {
>
> switch(count(func_get_args())) {
>
> case 1:
> call_user_func_array(array($this, '_helper1'), func_get_args());
> break;
> // and so on
> }
>
> }
>
> --
> Nilesh Govindarajan
> Site & Server Administrator
> www.itech7.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

And how would you docblock that?

Documentation is important as that describes the intent to the users
of the code.

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 12:06, Peter Lind wrote:
> Hmmm, that looks to me like you're trying to solve a problem in PHP
> with a c/c++c/# overloading solution. I'd give the builder pattern a
> try instead: http://en.wikipedia.org/wiki/Builder_pattern
>
> On 24 March 2010 13:01, Richard Quadling wrote:
>> Hi.
>>
>> I have a scenario where I would _like_ to have multiple constructors
>> for a class.
>>
>> Each constructor has a greater number of parameters than the previous one.
>>
>> e.g.
>>
>> >> class myClass {
>> __construct(string $Key) // use key to get the complex details.
>> __construct(string $Part1, string $Part2, string $Part3) //
>> Alternative route to the complex details.
>> __construct(array $Complex) // All the details
>> }
>>
>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>> and 3 are the main details and well documented defaults for the rest
>> of the rules. Complex is all the rules.
>>
>> Each constructor will end up with all the parts being known ($Key,
>> $Part1, $Part2, $Part3, $Complex).
>>
>> But, PHP doesn't support multiple constructors.
>>
>> Initially I thought about this ...
>>
>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>
>> But then documenting the first param as being 1 of three different
>> meanings is pretty much a no go.
>>
>> So I'm looking for a clean and easily understood way to provide this.
>>
>> I won't be the only user of the code and not everyone has the same
>> knowledge level, hence a mechanism that is easily documentable.
>>
>> I think I may need a factory with multiple methods (FactoryKey,
>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>> All these methods eventually call the real class with the complex
>> rule.
>>
>> Is that obvious enough?
>>
>> Regards,
>>
>> Richard.
>>
>>
>> --
>> -----
>> Richard Quadling
>> "Standing on the shoulders of some very clever giants!"
>> EE : http://www.experts-exchange.com/M_248814.html
>> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
>> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
>> ZOPA : http://uk.zopa.com/member/RQuadling
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
>
> 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
>
>

I'm not building different types of "pizza". Just the same pizza via
different routes.

Along the lines of ...

Pizza = new Pizza('MyFavouritePizza') // A ham+pineapple+cheese pizza.
Pizza = new Pizza('ham', 'pineapple', 'cheese'); // A generic
ham+pineapple+cheese pizza
Pizza = new Pizza(array('base' => 'thin', 'toppings' => array('ham',
'pineapple'), 'cheese'=>true)); // A complex description.

I suppose the interfaces are beginner, intermediate and advanced, but
ultimately all generate identical objects.

Richard.

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

And how exactly does that differ from building the same pizza in
different ways? Builder doesn't mean you have to create different
objects, it means taking the complexity in building a given object or
set of objects and storing it in one place.

In your case, it allows you to build your object in different ways
while documenting it properly and avoid the huge switch inside your
constructor that Nilesh proposed.

On 24 March 2010 13:35, Richard Quadling wrote:
> On 24 March 2010 12:06, Peter Lind wrote:
>> Hmmm, that looks to me like you're trying to solve a problem in PHP
>> with a c/c++c/# overloading solution. I'd give the builder pattern a
>> try instead: http://en.wikipedia.org/wiki/Builder_pattern
>>
>> On 24 March 2010 13:01, Richard Quadling wrote:
>>> Hi.
>>>
>>> I have a scenario where I would _like_ to have multiple constructors
>>> for a class.
>>>
>>> Each constructor has a greater number of parameters than the previous one.
>>>
>>> e.g.
>>>
>>> >>> class myClass {
>>> __construct(string $Key) // use key to get the complex details.
>>> __construct(string $Part1, string $Part2, string $Part3) //
>>> Alternative route to the complex details.
>>> __construct(array $Complex) // All the details
>>> }
>>>
>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>> and 3 are the main details and well documented defaults for the rest
>>> of the rules. Complex is all the rules.
>>>
>>> Each constructor will end up with all the parts being known ($Key,
>>> $Part1, $Part2, $Part3, $Complex).
>>>
>>> But, PHP doesn't support multiple constructors.
>>>
>>> Initially I thought about this ...
>>>
>>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>>
>>> But then documenting the first param as being 1 of three different
>>> meanings is pretty much a no go.
>>>
>>> So I'm looking for a clean and easily understood way to provide this.
>>>
>>> I won't be the only user of the code and not everyone has the same
>>> knowledge level, hence a mechanism that is easily documentable.
>>>
>>> I think I may need a factory with multiple methods (FactoryKey,
>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>> All these methods eventually call the real class with the complex
>>> rule.
>>>
>>> Is that obvious enough?
>>>
>>> Regards,
>>>
>>> Richard.
>>>
>>>
>>> --
>>> -----
>>> Richard Quadling
>>> "Standing on the shoulders of some very clever giants!"
>>> EE : http://www.experts-exchange.com/M_248814.html
>>> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
>>> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
>>> ZOPA : http://uk.zopa.com/member/RQuadling
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>
>>
>> --
>>
>> 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
>>
>>
>
> I'm not building different types of "pizza". Just the same pizza via
> different routes.
>
> Along the lines of ...
>
> Pizza = new Pizza('MyFavouritePizza') // A ham+pineapple+cheese pizza.
> Pizza = new Pizza('ham', 'pineapple', 'cheese'); // A generic
> ham+pineapple+cheese pizza
> Pizza = new Pizza(array('base' => 'thin', 'toppings' => array('ham',
> 'pineapple'), 'cheese'=>true)); // A complex description.
>
> I suppose the interfaces are beginner, intermediate and advanced, but
> ultimately all generate identical objects.
>
> Richard.
>
> --
> -----
> Richard Quadling
> "Standing on the shoulders of some very clever giants!"
> EE : http://www.experts-exchange.com/M_248814.html
> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> ZOPA : http://uk.zopa.com/member/RQuadling
>



--

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 12:39, Peter Lind wrote:
> And how exactly does that differ from building the same pizza in
> different ways? Builder doesn't mean you have to create different
> objects, it means taking the complexity in building a given object or
> set of objects and storing it in one place.
>
> In your case, it allows you to build your object in different ways
> while documenting it properly and avoid the huge switch inside your
> constructor that Nilesh proposed.
>
> On 24 March 2010 13:35, Richard Quadling wrote:
>> On 24 March 2010 12:06, Peter Lind wrote:
>>> Hmmm, that looks to me like you're trying to solve a problem in PHP
>>> with a c/c++c/# overloading solution. I'd give the builder pattern a
>>> try instead: http://en.wikipedia.org/wiki/Builder_pattern
>>>
>>> On 24 March 2010 13:01, Richard Quadling wrote:
>>>> Hi.
>>>>
>>>> I have a scenario where I would _like_ to have multiple constructors
>>>> for a class.
>>>>
>>>> Each constructor has a greater number of parameters than the previous one.
>>>>
>>>> e.g.
>>>>
>>>> >>>> class myClass {
>>>> __construct(string $Key) // use key to get the complex details.
>>>> __construct(string $Part1, string $Part2, string $Part3) //
>>>> Alternative route to the complex details.
>>>> __construct(array $Complex) // All the details
>>>> }
>>>>
>>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>>> and 3 are the main details and well documented defaults for the rest
>>>> of the rules. Complex is all the rules.
>>>>
>>>> Each constructor will end up with all the parts being known ($Key,
>>>> $Part1, $Part2, $Part3, $Complex).
>>>>
>>>> But, PHP doesn't support multiple constructors.
>>>>
>>>> Initially I thought about this ...
>>>>
>>>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>>>
>>>> But then documenting the first param as being 1 of three different
>>>> meanings is pretty much a no go.
>>>>
>>>> So I'm looking for a clean and easily understood way to provide this.
>>>>
>>>> I won't be the only user of the code and not everyone has the same
>>>> knowledge level, hence a mechanism that is easily documentable.
>>>>
>>>> I think I may need a factory with multiple methods (FactoryKey,
>>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>>> All these methods eventually call the real class with the complex
>>>> rule.
>>>>
>>>> Is that obvious enough?
>>>>
>>>> Regards,
>>>>
>>>> Richard.
>>>>
>>>>
>>>> --
>>>> -----
>>>> Richard Quadling
>>>> "Standing on the shoulders of some very clever giants!"
>>>> EE : http://www.experts-exchange.com/M_248814.html
>>>> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
>>>> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
>>>> ZOPA : http://uk.zopa.com/member/RQuadling
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>> I'm not building different types of "pizza". Just the same pizza via
>> different routes.
>>
>> Along the lines of ...
>>
>> Pizza = new Pizza('MyFavouritePizza') // A ham+pineapple+cheese pizza.
>> Pizza = new Pizza('ham', 'pineapple', 'cheese'); // A generic
>> ham+pineapple+cheese pizza
>> Pizza = new Pizza(array('base' => 'thin', 'toppings' => array('ham',
>> 'pineapple'), 'cheese'=>true)); // A complex description.
>>
>> I suppose the interfaces are beginner, intermediate and advanced, but
>> ultimately all generate identical objects.
>>
>> Richard.
>>
>> --
>> -----
>> Richard Quadling
>> "Standing on the shoulders of some very clever giants!"
>> EE : http://www.experts-exchange.com/M_248814.html
>> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
>> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
>> ZOPA : http://uk.zopa.com/member/RQuadling
>>
>
>
>
> --
>
> 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
>
>

Aha.

light bulb moment.

Thank you.


--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Richard Quadling wrote:
> Hi.
>
> I have a scenario where I would _like_ to have multiple constructors
> for a class.
>
> Each constructor has a greater number of parameters than the previous one.
>
> e.g.
>
> > class myClass {
> __construct(string $Key) // use key to get the complex details.
> __construct(string $Part1, string $Part2, string $Part3) //
> Alternative route to the complex details.
> __construct(array $Complex) // All the details
> }
>
> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
> and 3 are the main details and well documented defaults for the rest
> of the rules. Complex is all the rules.
>
> Each constructor will end up with all the parts being known ($Key,
> $Part1, $Part2, $Part3, $Complex).
>
> But, PHP doesn't support multiple constructors.
>
> Initially I thought about this ...
>
> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>
> But then documenting the first param as being 1 of three different
> meanings is pretty much a no go.
>
> So I'm looking for a clean and easily understood way to provide this.
>
> I won't be the only user of the code and not everyone has the same
> knowledge level, hence a mechanism that is easily documentable.
>
> I think I may need a factory with multiple methods (FactoryKey,
> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
> All these methods eventually call the real class with the complex
> rule.
>
> Is that obvious enough?

Factory method is probably the cleanest and simplest solution. Just pass
an ID as the first parameter to the real constructor and then it can
route to the appropriate behaviour:


$factory->getInstanceBleh();

class Foo
{
const SUPER_SPECIAL_BLEH = 1;
const SUPER_SPECIAL_BLAH = 2;
const SUPER_SPECIAL_BLUH = 3;

function __construct( $superSpecialId, ... )
{
switch( $superSpecialId )
{
}
}

function getInstanceBleh()
{
return new Foo( Foo::SUPER_SPECIAL_1 );
}
}

?>

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

Re: Properly handling multiple constructors.

On 03/24/2010 05:58 PM, Richard Quadling wrote:
> On 24 March 2010 12:08, Nilesh Govindarajan wrote:
>> On 03/24/2010 05:31 PM, Richard Quadling wrote:
>>>
>>> Hi.
>>>
>>> I have a scenario where I would _like_ to have multiple constructors
>>> for a class.
>>>
>>> Each constructor has a greater number of parameters than the previous one.
>>>
>>> e.g.
>>>
>>> >>> class myClass {
>>> __construct(string $Key) // use key to get the complex details.
>>> __construct(string $Part1, string $Part2, string $Part3) //
>>> Alternative route to the complex details.
>>> __construct(array $Complex) // All the details
>>> }
>>>
>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>> and 3 are the main details and well documented defaults for the rest
>>> of the rules. Complex is all the rules.
>>>
>>> Each constructor will end up with all the parts being known ($Key,
>>> $Part1, $Part2, $Part3, $Complex).
>>>
>>> But, PHP doesn't support multiple constructors.
>>>
>>> Initially I thought about this ...
>>>
>>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>>
>>> But then documenting the first param as being 1 of three different
>>> meanings is pretty much a no go.
>>>
>>> So I'm looking for a clean and easily understood way to provide this.
>>>
>>> I won't be the only user of the code and not everyone has the same
>>> knowledge level, hence a mechanism that is easily documentable.
>>>
>>> I think I may need a factory with multiple methods (FactoryKey,
>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>> All these methods eventually call the real class with the complex
>>> rule.
>>>
>>> Is that obvious enough?
>>>
>>> Regards,
>>>
>>> Richard.
>>>
>>>
>>
>> Don't give specify any parameters in the function declaration.
>>
>> Use helper functions inside the class, and decide at the constructor which
>> helper to call using func_get_arg() and func_get_args()
>>
>> You can get the no. of arguments using count(func_get_args())
>>
>> and then using swtich statement call the relevant helper function using
>> call_user_func_array with parameters.
>>
>> A sample:
>>
>> public function __construct() {
>>
>> switch(count(func_get_args())) {
>>
>> case 1:
>> call_user_func_array(array($this, '_helper1'), func_get_args());
>> break;
>> // and so on
>> }
>>
>> }
>>
>> --
>> Nilesh Govindarajan
>> Site& Server Administrator
>> www.itech7.com
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> And how would you docblock that?
>
> Documentation is important as that describes the intent to the users
> of the code.
>

In this method documentation cannot be generated by doxygen or
phpDocumenter, etc.

You will have to write the documentation by your own.

I don't see any other solution to your c++ like constructor overloading
problem.

If anyone else knows on this list, I will surely like to know what it is :)

--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Robert Cummings wrote:
> Richard Quadling wrote:
>> Hi.
>>
>> I have a scenario where I would _like_ to have multiple constructors
>> for a class.
>>
>> Each constructor has a greater number of parameters than the previous one.
>>
>> e.g.
>>
>> >> class myClass {
>> __construct(string $Key) // use key to get the complex details.
>> __construct(string $Part1, string $Part2, string $Part3) //
>> Alternative route to the complex details.
>> __construct(array $Complex) // All the details
>> }
>>
>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>> and 3 are the main details and well documented defaults for the rest
>> of the rules. Complex is all the rules.
>>
>> Each constructor will end up with all the parts being known ($Key,
>> $Part1, $Part2, $Part3, $Complex).
>>
>> But, PHP doesn't support multiple constructors.
>>
>> Initially I thought about this ...
>>
>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>
>> But then documenting the first param as being 1 of three different
>> meanings is pretty much a no go.
>>
>> So I'm looking for a clean and easily understood way to provide this.
>>
>> I won't be the only user of the code and not everyone has the same
>> knowledge level, hence a mechanism that is easily documentable.
>>
>> I think I may need a factory with multiple methods (FactoryKey,
>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>> All these methods eventually call the real class with the complex
>> rule.
>>
>> Is that obvious enough?
>
> Factory method is probably the cleanest and simplest solution. Just pass
> an ID as the first parameter to the real constructor and then it can
> route to the appropriate behaviour:

Here's a better example (tested):


class Foo
{
const CONSTRUCT_BLAH = 1;
const CONSTRUCT_BLEH = 2;
const CONSTRUCT_BLUH = 3;

function __construct( $constructId )
{
static $map = array
(
self::CONSTRUCT_BLAH => '__construct_blah',
self::CONSTRUCT_BLEH => '__construct_bleh',
self::CONSTRUCT_BLUH => '__construct_bluh',
);

$obj = null;

if( isset( $map[$constructId] ) )
{
$args = func_get_args();
$args = array_shift( $args );

call_user_func_array(
array( 'self', $map[$constructId] ), $args );
}
else
{
// Generate an error or exception.
}
}

static function __construct_bleh( $arg1 )
{
echo "Called: ".__FUNCTION__."( $arg1 )\n";
}

static function __construct_blah( $arg1 )
{
echo "Called: ".__FUNCTION__."( $arg1 )\n";
}

static function __construct_bluh( $arg1 )
{
echo "Called: ".__FUNCTION__."( $arg1 )\n";
}

static function getBlah( $arg1 )
{
return new Foo( self::CONSTRUCT_BLAH, $arg1 );
}

static function getBleh( $arg1 )
{
return new Foo( self::CONSTRUCT_BLEH, $arg1 );
}

static function getBluh( $arg1 )
{
return new Foo( self::CONSTRUCT_BLUH, $arg1 );
}
}

$obj = Foo::getBlah( 'blah' );
$obj = Foo::getBleh( 'bleh' );
$obj = Foo::getBluh( 'bluh' );

?>

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

Re: Properly handling multiple constructors.

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.

Quick note: __ prefixed functions are "reserved", you shouldn't use
that prefix for any of your own functions. However unlikely it is that
PHP will ever have a __construct_bluh() function ...

On 24 March 2010 15:22, Robert Cummings wrote:
> Robert Cummings wrote:
>>
>> Richard Quadling wrote:
>>>
>>> Hi.
>>>
>>> I have a scenario where I would _like_ to have multiple constructors
>>> for a class.
>>>
>>> Each constructor has a greater number of parameters than the previous
>>> one.
>>>
>>> e.g.
>>>
>>> >>> class myClass {
>>> __construct(string $Key) // use key to get the complex details.
>>> __construct(string $Part1, string $Part2, string $Part3) //
>>> Alternative route to the complex details.
>>> __construct(array $Complex) // All the details
>>> }
>>>
>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>> and 3 are the main details and well documented defaults for the rest
>>> of the rules. Complex is all the rules.
>>>
>>> Each constructor will end up with all the parts being known ($Key,
>>> $Part1, $Part2, $Part3, $Complex).
>>>
>>> But, PHP doesn't support multiple constructors.
>>>
>>> Initially I thought about this ...
>>>
>>> __construct($Key_Part1_Complex, $Part2=3DNull, $Part3=3DNull)
>>>
>>> But then documenting the first param as being 1 of three different
>>> meanings is pretty much a no go.
>>>
>>> So I'm looking for a clean and easily understood way to provide this.
>>>
>>> I won't be the only user of the code and not everyone has the same
>>> knowledge level, hence a mechanism that is easily documentable.
>>>
>>> I think I may need a factory with multiple methods (FactoryKey,
>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>> All these methods eventually call the real class with the complex
>>> rule.
>>>
>>> Is that obvious enough?
>>
>> Factory method is probably the cleanest and simplest solution. Just pass
>> an ID as the first parameter to the real constructor and then it can rou=
te
>> to the appropriate behaviour:
>
> Here's a better example (tested):
>
> >
> class Foo
> {
>    const CONSTRUCT_BLAH =3D 1;
>    const CONSTRUCT_BLEH =3D 2;
>    const CONSTRUCT_BLUH =3D 3;
>
>    function __construct( $constructId )
>    {
>        static $map =3D array
>        (
>            self::CONSTRUCT_BLAH =3D> '__con=
struct_blah',
>            self::CONSTRUCT_BLEH =3D> '__con=
struct_bleh',
>            self::CONSTRUCT_BLUH =3D> '__con=
struct_bluh',
>        );
>
>        $obj =3D null;
>
>        if( isset( $map[$constructId] ) )
>        {
>            $args =3D func_get_args();
>            $args =3D array_shift( $args );
>
>            call_user_func_array(
>                array( 'self', $ma=
p[$constructId] ), $args );
>        }
>        else
>        {
>            // Generate an error or exceptio=
n.
>        }
>    }
>
>    static function __construct_bleh( $arg1 )
>    {
>        echo "Called: ".__FUNCTION__."( $arg1 )\n";
>    }
>
>    static function __construct_blah( $arg1 )
>    {
>        echo "Called: ".__FUNCTION__."( $arg1 )\n";
>    }
>
>    static function __construct_bluh( $arg1 )
>    {
>        echo "Called: ".__FUNCTION__."( $arg1 )\n";
>    }
>
>    static function getBlah( $arg1 )
>    {
>        return new Foo( self::CONSTRUCT_BLAH, $arg1 );
>    }
>
>    static function getBleh( $arg1 )
>    {
>        return new Foo( self::CONSTRUCT_BLEH, $arg1 );
>    }
>
>    static function getBluh( $arg1 )
>    {
>        return new Foo( self::CONSTRUCT_BLUH, $arg1 );
>    }
> }
>
> $obj =3D Foo::getBlah( 'blah' );
> $obj =3D Foo::getBleh( 'bleh' );
> $obj =3D Foo::getBluh( 'bluh' );
>
> ?>
>
> 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
>
>



--=20

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Robert Cummings wrote:
> Robert Cummings wrote:
>> Richard Quadling wrote:
>>> Hi.
>>>
>>> I have a scenario where I would _like_ to have multiple constructors
>>> for a class.
>>>
>>> Each constructor has a greater number of parameters than the previous one.
>>>
>>> e.g.
>>>
>>> >>> class myClass {
>>> __construct(string $Key) // use key to get the complex details.
>>> __construct(string $Part1, string $Part2, string $Part3) //
>>> Alternative route to the complex details.
>>> __construct(array $Complex) // All the details
>>> }
>>>
>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>> and 3 are the main details and well documented defaults for the rest
>>> of the rules. Complex is all the rules.
>>>
>>> Each constructor will end up with all the parts being known ($Key,
>>> $Part1, $Part2, $Part3, $Complex).
>>>
>>> But, PHP doesn't support multiple constructors.
>>>
>>> Initially I thought about this ...
>>>
>>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>>
>>> But then documenting the first param as being 1 of three different
>>> meanings is pretty much a no go.
>>>
>>> So I'm looking for a clean and easily understood way to provide this.
>>>
>>> I won't be the only user of the code and not everyone has the same
>>> knowledge level, hence a mechanism that is easily documentable.
>>>
>>> I think I may need a factory with multiple methods (FactoryKey,
>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>> All these methods eventually call the real class with the complex
>>> rule.
>>>
>>> Is that obvious enough?
>> Factory method is probably the cleanest and simplest solution. Just pass
>> an ID as the first parameter to the real constructor and then it can
>> route to the appropriate behaviour:
>
> Here's a better example (tested):
>
> >
> class Foo
> {
> const CONSTRUCT_BLAH = 1;
> const CONSTRUCT_BLEH = 2;
> const CONSTRUCT_BLUH = 3;
>
> function __construct( $constructId )
> {
> static $map = array
> (
> self::CONSTRUCT_BLAH => '__construct_blah',
> self::CONSTRUCT_BLEH => '__construct_bleh',
> self::CONSTRUCT_BLUH => '__construct_bluh',
> );
>
> $obj = null;
>
> if( isset( $map[$constructId] ) )
> {
> $args = func_get_args();
> $args = array_shift( $args );

Whoops... didn't read my output carefully enough... the above line
should be:

array_shift( $args )

Without the re-assignment (I don't use array_shift() often :)

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

Re: Properly handling multiple constructors.

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.

> Quick note: __ prefixed functions are "reserved", you shouldn't use
> that prefix for any of your own functions. However unlikely it is that
> PHP will ever have a __construct_bluh() function ...

Yeah, I know... I threw caution to the wind in this quick example. But
for the sake of archives and newbies reading them, I shouldn't have :)

Cheers,
Rob.


>
> On 24 March 2010 15:22, Robert Cummings wrote:
>> Robert Cummings wrote:
>>> Richard Quadling wrote:
>>>> Hi.
>>>>
>>>> I have a scenario where I would _like_ to have multiple constructors
>>>> for a class.
>>>>
>>>> Each constructor has a greater number of parameters than the previous
>>>> one.
>>>>
>>>> e.g.
>>>>
>>>> >>>> class myClass {
>>>> __construct(string $Key) // use key to get the complex details.
>>>> __construct(string $Part1, string $Part2, string $Part3) //
>>>> Alternative route to the complex details.
>>>> __construct(array $Complex) // All the details
>>>> }
>>>>
>>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
>>>> and 3 are the main details and well documented defaults for the rest
>>>> of the rules. Complex is all the rules.
>>>>
>>>> Each constructor will end up with all the parts being known ($Key,
>>>> $Part1, $Part2, $Part3, $Complex).
>>>>
>>>> But, PHP doesn't support multiple constructors.
>>>>
>>>> Initially I thought about this ...
>>>>
>>>> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>>>>
>>>> But then documenting the first param as being 1 of three different
>>>> meanings is pretty much a no go.
>>>>
>>>> So I'm looking for a clean and easily understood way to provide this.
>>>>
>>>> I won't be the only user of the code and not everyone has the same
>>>> knowledge level, hence a mechanism that is easily documentable.
>>>>
>>>> I think I may need a factory with multiple methods (FactoryKey,
>>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
>>>> All these methods eventually call the real class with the complex
>>>> rule.
>>>>
>>>> Is that obvious enough?
>>> Factory method is probably the cleanest and simplest solution. Just pass
>>> an ID as the first parameter to the real constructor and then it can route
>>> to the appropriate behaviour:
>> Here's a better example (tested):
>>
>> >>
>> class Foo
>> {
>> const CONSTRUCT_BLAH = 1;
>> const CONSTRUCT_BLEH = 2;
>> const CONSTRUCT_BLUH = 3;
>>
>> function __construct( $constructId )
>> {
>> static $map = array
>> (
>> self::CONSTRUCT_BLAH => '__construct_blah',
>> self::CONSTRUCT_BLEH => '__construct_bleh',
>> self::CONSTRUCT_BLUH => '__construct_bluh',
>> );
>>
>> $obj = null;
>>
>> if( isset( $map[$constructId] ) )
>> {
>> $args = func_get_args();
>> $args = array_shift( $args );
>>
>> call_user_func_array(
>> array( 'self', $map[$constructId] ), $args );
>> }
>> else
>> {
>> // Generate an error or exception.
>> }
>> }
>>
>> static function __construct_bleh( $arg1 )
>> {
>> echo "Called: ".__FUNCTION__."( $arg1 )\n";
>> }
>>
>> static function __construct_blah( $arg1 )
>> {
>> echo "Called: ".__FUNCTION__."( $arg1 )\n";
>> }
>>
>> static function __construct_bluh( $arg1 )
>> {
>> echo "Called: ".__FUNCTION__."( $arg1 )\n";
>> }
>>
>> static function getBlah( $arg1 )
>> {
>> return new Foo( self::CONSTRUCT_BLAH, $arg1 );
>> }
>>
>> static function getBleh( $arg1 )
>> {
>> return new Foo( self::CONSTRUCT_BLEH, $arg1 );
>> }
>>
>> static function getBluh( $arg1 )
>> {
>> return new Foo( self::CONSTRUCT_BLUH, $arg1 );
>> }
>> }
>>
>> $obj = Foo::getBlah( 'blah' );
>> $obj = Foo::getBleh( 'bleh' );
>> $obj = Foo::getBluh( 'bluh' );
>>
>> ?>
>>
>> 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
>>
>>
>
>
>

--
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

Re: Properly handling multiple constructors.

On 24 March 2010 15:33, Robert Cummings 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 o=
wn
> 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 $some=
thing
* @param string|array|object|whatever_you_could_think_to_throw_at_it
$something this is optional
* @param etc
*
* @access public
* @return void
*/
>> Quick note: __ prefixed functions are "reserved", you shouldn't use
>> that prefix for any of your own functions. However unlikely it is that
>> PHP will ever have a __construct_bluh() function ...
>
> Yeah, I know... I threw caution to the wind in this quick example. But fo=
r
> the sake of archives and newbies reading them, I shouldn't have :)
>
> Cheers,
> Rob.
>
>
>>
>> On 24 March 2010 15:22, Robert Cummings wrote:
>>>
>>> Robert Cummings wrote:
>>>>
>>>> Richard Quadling wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> I have a scenario where I would _like_ to have multiple constructors
>>>>> for a class.
>>>>>
>>>>> Each constructor has a greater number of parameters than the previous
>>>>> one.
>>>>>
>>>>> e.g.
>>>>>
>>>>> >>>>> class myClass {
>>>>> __construct(string $Key) // use key to get the complex details.
>>>>> __construct(string $Part1, string $Part2, string $Part3) //
>>>>> Alternative route to the complex details.
>>>>> __construct(array $Complex) // All the details
>>>>> }
>>>>>
>>>>> Essentially, SimpleKey is a key to a set of predefined rules. Part1, =
2
>>>>> and 3 are the main details and well documented defaults for the rest
>>>>> of the rules. Complex is all the rules.
>>>>>
>>>>> Each constructor will end up with all the parts being known ($Key,
>>>>> $Part1, $Part2, $Part3, $Complex).
>>>>>
>>>>> But, PHP doesn't support multiple constructors.
>>>>>
>>>>> Initially I thought about this ...
>>>>>
>>>>> __construct($Key_Part1_Complex, $Part2=3DNull, $Part3=3DNull)
>>>>>
>>>>> But then documenting the first param as being 1 of three different
>>>>> meanings is pretty much a no go.
>>>>>
>>>>> So I'm looking for a clean and easily understood way to provide this.
>>>>>
>>>>> I won't be the only user of the code and not everyone has the same
>>>>> knowledge level, hence a mechanism that is easily documentable.
>>>>>
>>>>> I think I may need a factory with multiple methods (FactoryKey,
>>>>> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton=
..
>>>>> All these methods eventually call the real class with the complex
>>>>> rule.
>>>>>
>>>>> Is that obvious enough?
>>>>
>>>> Factory method is probably the cleanest and simplest solution. Just pa=
ss
>>>> an ID as the first parameter to the real constructor and then it can
>>>> route
>>>> to the appropriate behaviour:
>>>
>>> Here's a better example (tested):
>>>
>>> >>>
>>> class Foo
>>> {
>>>   const CONSTRUCT_BLAH =3D 1;
>>>   const CONSTRUCT_BLEH =3D 2;
>>>   const CONSTRUCT_BLUH =3D 3;
>>>
>>>   function __construct( $constructId )
>>>   {
>>>       static $map =3D array
>>>       (
>>>           self::CONSTRUCT_BLAH =3D> '__constru=
ct_blah',
>>>           self::CONSTRUCT_BLEH =3D> '__constru=
ct_bleh',
>>>           self::CONSTRUCT_BLUH =3D> '__constru=
ct_bluh',
>>>       );
>>>
>>>       $obj =3D null;
>>>
>>>       if( isset( $map[$constructId] ) )
>>>       {
>>>           $args =3D func_get_args();
>>>           $args =3D array_shift( $args );
>>>
>>>           call_user_func_array(
>>>               array( 'self', $map[$c=
onstructId] ), $args );
>>>       }
>>>       else
>>>       {
>>>           // Generate an error or exception.
>>>       }
>>>   }
>>>
>>>   static function __construct_bleh( $arg1 )
>>>   {
>>>       echo "Called: ".__FUNCTION__."( $arg1 )\n";
>>>   }
>>>
>>>   static function __construct_blah( $arg1 )
>>>   {
>>>       echo "Called: ".__FUNCTION__."( $arg1 )\n";
>>>   }
>>>
>>>   static function __construct_bluh( $arg1 )
>>>   {
>>>       echo "Called: ".__FUNCTION__."( $arg1 )\n";
>>>   }
>>>
>>>   static function getBlah( $arg1 )
>>>   {
>>>       return new Foo( self::CONSTRUCT_BLAH, $arg1 );
>>>   }
>>>
>>>   static function getBleh( $arg1 )
>>>   {
>>>       return new Foo( self::CONSTRUCT_BLEH, $arg1 );
>>>   }
>>>
>>>   static function getBluh( $arg1 )
>>>   {
>>>       return new Foo( self::CONSTRUCT_BLUH, $arg1 );
>>>   }
>>> }
>>>
>>> $obj =3D Foo::getBlah( 'blah' );
>>> $obj =3D Foo::getBleh( 'bleh' );
>>> $obj =3D Foo::getBluh( 'bluh' );
>>>
>>> ?>
>>>
>>> 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
>>>
>>>
>>
>>
>>
>
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>



--=20

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Peter Lind wrote:
> On 24 March 2010 15:33, Robert Cummings 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.

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

Re: Properly handling multiple constructors.

The following code (which cannot currently work as PHP does not allow
for method overloading) would be perfect for me.

class DataConnector {
/**
* Rules
*
* What rules does this data connector use.
*
* @param Zend_Config
*/
private $Rules = Null;

/**
* Constructor : Keyed
*
* This constructor will access the main registry to determine which
pre-saved rules to use.
*
* @param string $Key The registry key.
*
* @return DataConnector
*/
public function __construct($Key) {
// Use the key to retrieve the rules for this connector.
$this->__construct(registry::RetrieveViaKey(__CLASS__, $Key));
}

/**
* Constructor : Partial
*
* This constructor will construct the rules from the default
template and populate the 3 critical ones.
*
* @param string $Part1
* @param string $Part2
* @param string $Part3
*
* @return DataConnector
*/
public function __construct($Part1, $Part2, $Part3) {
// Use the Parts to construct the rules for this connector.
$Rules = registry::RetrieveDefault(__CLASS__);
$Rules->setPart1 = $Part1;
$Rules->setPart2 = $Part2;
$Rules->setPart3 = $Part3;
$this->__construct($Rules);
}

/**
* Constructor : Complete
*
* This constructor will take the supplied config and apply it to the rules.
*
* @param Zend_Config $Rules
*
* @return DataConnector
*/
public function __construct(Zend_Config $Rules) {
// Use the supplied rules
$this->Rules = $Rules;
$this->Init();
}

/**
* Post construction processing
*/
protected function Init() {
}

/**
* Store configuration in the registry.
*
* @param string $Key Allow for a new key to be used.
*
* @return DataConnector
*/
public function Store($Key = Null) {
$this->Rules['Key'] = $Key ?: $this->Rules['Key'];
registry::Store(__CLASS__, $this->Rules);
return $this;
}
}
?>



--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 16:09, Robert Cummings wrote:
>
>
> Peter Lind wrote:
>>
>> On 24 March 2010 15:33, Robert Cummings 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 t=
o 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
>



--=20

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Peter Lind wrote:
> On 24 March 2010 16:09, Robert Cummings wrote:
>>
>> Peter Lind wrote:
>>> On 24 March 2010 15:33, Robert Cummings 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

Re: Properly handling multiple constructors.

Richard Quadling wrote:
> The following code (which cannot currently work as PHP does not allow
> for method overloading) would be perfect for me.
>
> > class DataConnector {
> /**
> * Rules
> *
> * What rules does this data connector use.
> *
> * @param Zend_Config
> */
> private $Rules = Null;
>
> /**
> * Constructor : Keyed
> *
> * This constructor will access the main registry to determine which
> pre-saved rules to use.
> *
> * @param string $Key The registry key.
> *
> * @return DataConnector
> */
> public function __construct($Key) {
> // Use the key to retrieve the rules for this connector.
> $this->__construct(registry::RetrieveViaKey(__CLASS__, $Key));
> }
>
> /**
> * Constructor : Partial
> *
> * This constructor will construct the rules from the default
> template and populate the 3 critical ones.
> *
> * @param string $Part1
> * @param string $Part2
> * @param string $Part3
> *
> * @return DataConnector
> */
> public function __construct($Part1, $Part2, $Part3) {
> // Use the Parts to construct the rules for this connector.
> $Rules = registry::RetrieveDefault(__CLASS__);
> $Rules->setPart1 = $Part1;
> $Rules->setPart2 = $Part2;
> $Rules->setPart3 = $Part3;
> $this->__construct($Rules);
> }
>
> /**
> * Constructor : Complete
> *
> * This constructor will take the supplied config and apply it to the rules.
> *
> * @param Zend_Config $Rules
> *
> * @return DataConnector
> */
> public function __construct(Zend_Config $Rules) {
> // Use the supplied rules
> $this->Rules = $Rules;
> $this->Init();
> }
>
> /**
> * Post construction processing
> */
> protected function Init() {
> }
>
> /**
> * Store configuration in the registry.
> *
> * @param string $Key Allow for a new key to be used.
> *
> * @return DataConnector
> */
> public function Store($Key = Null) {
> $this->Rules['Key'] = $Key ?: $this->Rules['Key'];
> registry::Store(__CLASS__, $this->Rules);
> return $this;
> }
> }
> ?>

Are you asking a question? I'm not sure what you want here :) Does the
technique I sent provide you with a solution to this problem or not?

:)

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

Re: Properly handling multiple constructors.

On 24 March 2010 16:23, Robert Cummings wrote:
> Peter Lind wrote:
>>
>> On 24 March 2010 16:09, Robert Cummings wrote:
>>>
>>> Peter Lind wrote:
>>>>
>>>> On 24 March 2010 15:33, Robert Cummings 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_a=
t_it
>>>> $something
>>>>  * @param string|array|object|whatever_you_could_think_to_throw_a=
t_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 fo=
r
>>>>  * 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 f=
or
>>> 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 w=
hen
> really they are the same, just built differently. In this context you hav=
e
> even more document points to review since you must read the class
> information in addition to the method signature. Also using a separate cl=
ass
> just to facilitate a different constructor seems abusive of class semanti=
cs
> 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
>



--=20

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 15:27, Robert Cummings wrote:
> Are you asking a question? I'm not sure what you want here :) Does the
> technique I sent provide you with a solution to this problem or not?

I can certainly see how your suggestion works.

And in my own code, I've often misused a method param list like this,
but that code never leaves my scratch area and is hardly ever
documented (ok, I'll be honest - there is nothing in the scratch area
which is documented!).

Does having static methods to funnel to the main constructor (which is
really always the complex one) make more sense here?

That way it is self contained and no need to have any misuse and no
additional classes.

static function GetConnectorUsingKey($Key) {}
static function GetConnectorUsingPartialData($Part1, $Part2, $Part3) {}
static function GetConnectorUsingRules(Zend_Config $Rules) {}

each returning a new DataConnector().


This looks easy to understand. The main constructor doesn't need to be
hidden (GetConnectorUsingRules() is a static alias of __construct()).


All looks ok?




--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Peter Lind wrote:
>>>> 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.

Absolutely, delegating responsibility to manage complexity is very good.
My proposed solution does this.

> 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.

No, you're getting different objects. If they come from different
classes then they are different. Yes they may be subclasses, but the OP
indicated they differ only by how they are built. Adding 10 different
subclasses just to facilitate constructor overloading seems egregious,
especially if the object already has logical subclasses.

class Dog
class Dog_construct1 extends Dog
class Dog_construct2 extends Dog
class Dog_construct3 extends Dog
class Dog_construct4 extends Dog

class Dalmation extends Dog
class Dalmation_construct1 extends Dog_construct1
class Dalmation_construct2 extends Dog_construct2
class Dalmation_construct3 extends Dog_construct3
class Dalmation_construct4 extends Dog_construct4

But now Dalmation_construct1 isn't related to Dalmation... or do you
propose the following:

class Dalmation extends Dalmation
class Dalmation_construct1 extends Dalmation
class Dalmation_construct2 extends Dalmation
class Dalmation_construct3 extends Dalmation
class Dalmation_construct4 extends Dalmation

But now Dalmation_construct1 isn't related Dog_construct1. This seems
problematic from a design perspective unless I'm missing something in
your proposal.

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.

Sorry, switches, foreach, and isset are not equivalent. My approach is
O( lg n ). Foreach and switches are O( n ) to find a candidate.
Additionally, my constructor does 1 thing, it delegates to the
appropriate constructor which does one thing also... builds the object
according to intent.

> 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?

No, I said probably because I put classes in separate files. I was
saying there is probably another added maintenance headache of all these
new class files.

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

Re: Properly handling multiple constructors.

Richard Quadling wrote:
> On 24 March 2010 15:27, Robert Cummings wrote:
>> Are you asking a question? I'm not sure what you want here :) Does the
>> technique I sent provide you with a solution to this problem or not?
>
> I can certainly see how your suggestion works.
>
> And in my own code, I've often misused a method param list like this,
> but that code never leaves my scratch area and is hardly ever
> documented (ok, I'll be honest - there is nothing in the scratch area
> which is documented!).
>
> Does having static methods to funnel to the main constructor (which is
> really always the complex one) make more sense here?
>
> That way it is self contained and no need to have any misuse and no
> additional classes.
>
> static function GetConnectorUsingKey($Key) {}
> static function GetConnectorUsingPartialData($Part1, $Part2, $Part3) {}
> static function GetConnectorUsingRules(Zend_Config $Rules) {}
>
> each returning a new DataConnector().
>
>
> This looks easy to understand. The main constructor doesn't need to be
> hidden (GetConnectorUsingRules() is a static alias of __construct()).
>
>
> All looks ok?

Yes you can do that also, you seemed to want constructors though :) As
for misused... variable parameters with mixed types is common enough
that I wouldn't call it misuse. It's succinct and solves a problem. Look
at the printf() family of functions.

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

Re: Properly handling multiple constructors.

On 24 March 2010 16:48, Robert Cummings wrote:
> Peter Lind wrote:
>>>>>
>>>>> 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 rathe=
r
>>> 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.
>
> Absolutely, delegating responsibility to manage complexity is very good. =
My
> proposed solution does this.
>
>> 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.
>
> No, you're getting different objects. If they come from different classes
> then they are different. Yes they may be subclasses, but the OP indicated
> they differ only by how they are built. Adding 10 different subclasses ju=
st
> to facilitate constructor overloading seems egregious, especially if the
> object already has logical subclasses.

As I suspected, you didn't understand what I meant. The builder
pattern lets you build complex objects in steps, separating out
complexity. It's equally well suited to building one object as many
objects and what I had in mind was a simplified builder/factory.

Which means you have:

class ObjectBuilder
class Object

where ObjectBuilder comes with several different ways of building
Object. That's two objects, not the list of objects extending
something you posted.

>    class Dog
>    class Dog_construct1 extends Dog
>    class Dog_construct2 extends Dog
>    class Dog_construct3 extends Dog
>    class Dog_construct4 extends Dog
>
>    class Dalmation extends Dog
>    class Dalmation_construct1 extends Dog_construct1
>    class Dalmation_construct2 extends Dog_construct2
>    class Dalmation_construct3 extends Dog_construct3
>    class Dalmation_construct4 extends Dog_construct4
>
> But now Dalmation_construct1 isn't related to Dalmation... or do you prop=
ose
> the following:
>
>    class Dalmation extends Dalmation
>    class Dalmation_construct1 extends Dalmation
>    class Dalmation_construct2 extends Dalmation
>    class Dalmation_construct3 extends Dalmation
>    class Dalmation_construct4 extends Dalmation
>
> But now Dalmation_construct1 isn't related Dog_construct1. This seems
> problematic from a design perspective unless I'm missing something in you=
r
> proposal.
>
>  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.
>
> Sorry, switches, foreach, and isset are not equivalent. My approach is O(=
lg
> n ). Foreach and switches are O( n ) to find a candidate. Additionally, m=
y
> constructor does 1 thing, it delegates to the appropriate constructor whi=
ch
> does one thing also... builds the object according to intent.

Yes, your constructor does one thing, which is indirectly related to
constructing instead of carrying out the actual constructing. I prefer
constructors to construct something, but that's a matter of preference
I expect.

>>  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 i=
n
>>> separate files), more points of management.
>>
>> Yes. What does your code look like? One big file containing everything?
>
> No, I said probably because I put classes in separate files. I was saying
> there is probably another added maintenance headache of all these new cla=
ss
> files.

There would be if one were to use your scheme of subclassing. What I
proposed doesn't do that in any way, so there's not much of a
maintenance headache.

Anyway, all this is theoretical seeing as you can equally well use a
set of static methods on the object to achieve the creation (the only
difference to what I proposed is which class the constructing methods
are in) and that solution seems to suit the OP.

> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>



--=20

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


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

On 24 March 2010 15:51, Robert Cummings wrote:
> Yes you can do that also, you seemed to want constructors though :) As for
> misused... variable parameters with mixed types is common enough that I
> wouldn't call it misuse. It's succinct and solves a problem. Look at the
> printf() family of functions.

As multiple constructors were a no-go, I wanted an alternative. As I'm
working on this, I'm getting feedback from other people. The connector
needs to be a singleton - this is currently missing from the original
app. Something I wasn't told! (Well, maybe someone may have mentioned
it once). The static "constructors" (for that is what they end up
doing) along with the appropriate singleton logic would seem to
suffice and be a perfect match.

Thanks for all your help.

I'm trying to learn ZF as well as port this unfinished app.

Regards,

Richard.

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Properly handling multiple constructors.

Peter Lind wrote:
> On 24 March 2010 16:48, Robert Cummings wrote:
>>
>> But now Dalmation_construct1 isn't related Dog_construct1. This seems
>> problematic from a design perspective unless I'm missing something in your
>> proposal.
>>
>> 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.
>> Sorry, switches, foreach, and isset are not equivalent. My approach is O( lg
>> n ). Foreach and switches are O( n ) to find a candidate. Additionally, my
>> constructor does 1 thing, it delegates to the appropriate constructor which
>> does one thing also... builds the object according to intent.

Well that clarifies a whole lot in my mind. Although I do prefer my
particular take on it, yours is obviously quite clean also :)

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

Re: Properly handling multiple constructors.

On 3/24/10 11:06 AM, Richard Quadling wrote:
> On 24 March 2010 15:51, Robert Cummings wrote:
>> Yes you can do that also, you seemed to want constructors though :) As for
>> misused... variable parameters with mixed types is common enough that I
>> wouldn't call it misuse. It's succinct and solves a problem. Look at the
>> printf() family of functions.
>
> As multiple constructors were a no-go, I wanted an alternative. As I'm
> working on this, I'm getting feedback from other people. The connector
> needs to be a singleton - this is currently missing from the original
> app. Something I wasn't told! (Well, maybe someone may have mentioned
> it once). The static "constructors" (for that is what they end up
> doing) along with the appropriate singleton logic would seem to
> suffice and be a perfect match.
>
> Thanks for all your help.
>
> I'm trying to learn ZF as well as port this unfinished app.
>
> Regards,
>
> Richard.

This actually sounds like a factory to me. You want to move some of
that logic out of the pizza object entirely.

class PizzaHut {

public function getByKey($key) {
$properties = $this->lookupFavorite($key);
return new Pizza($properties);
}

public function getByProperties($properties) {
return new Pizza($properties);
}

public function getByDefinition($base, $toppings, $cheese) {
$properties = array(
'base' => $base,
'toppings' => $toppings,
'cheese' => $cheese,
)
return new Pizza($properties);
}
}

$factory = new PizzaHut();
$pizza = $factory->getByKey("MyFavorite");
$pizza = $factory->getByProperties(...);

And so on. The Pizza class is now responsible for one thing: Being
pizza. MAKING a pizza is not the pizza's job, it's PizzaHut's job. All
of the methods of PizzaHut can be cleanly documented, and you can add
more ways of making Pizza without having to modify the Pizza class, and
all of them return a pizza that looks identical. You could even create
a Domino's class, too, to build pizza in an entirely different way but
still get a pizza when you're done.

You may want to go as far as making each of those properties a set
method rather than a big array of properties, but I leave that as an
exercise to the reader. (I grow less enamored with big, hard to
document arrays every time I use them.)

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php