Re: [PHP] 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 rquadl...@googlemail.com 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.
?php
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=ZEND002498r=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
--
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
Re: [PHP] 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.
?php
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: [PHP] 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.
?php
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: [PHP] Properly handling multiple constructors.
On 24 March 2010 12:08, Nilesh Govindarajan li...@itech7.com 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.
?php
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=ZEND002498r=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: [PHP] Properly handling multiple constructors.
On 24 March 2010 12:06, Peter Lind peter.e.l...@gmail.com 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 rquadl...@googlemail.com 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.
?php
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=ZEND002498r=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
--
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
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=ZEND002498r=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: [PHP] 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 rquadl...@googlemail.com wrote:
On 24 March 2010 12:06, Peter Lind peter.e.l...@gmail.com 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 rquadl...@googlemail.com 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.
?php
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=ZEND002498r=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
--
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
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=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
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
Re: [PHP] Properly handling multiple constructors.
On 24 March 2010 12:39, Peter Lind peter.e.l...@gmail.com 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 rquadl...@googlemail.com wrote:
On 24 March 2010 12:06, Peter Lind peter.e.l...@gmail.com 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 rquadl...@googlemail.com 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.
?php
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=ZEND002498r=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
--
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
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=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
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
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=ZEND002498r=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: [PHP] 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.
?php
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:
?php
$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: [PHP] Properly handling multiple constructors.
On 03/24/2010 05:58 PM, Richard Quadling wrote:
On 24 March 2010 12:08, Nilesh Govindarajanli...@itech7.com 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.
?php
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: [PHP] 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.
?php
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):
?php
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: [PHP] 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 rob...@interjinn.com 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.
?php
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):
?php
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
--
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
Re: [PHP] 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.
?php
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):
?php
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: [PHP] 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 rob...@interjinn.com 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.
?php
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):
?php
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: [PHP] Properly handling multiple constructors.
On 24 March 2010 15:33, Robert Cummings rob...@interjinn.com 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
*/
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 rob...@interjinn.com 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.
?php
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):
?php
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
--
hype
WWW: http://plphp.dk / http://plind.dk
Re: [PHP] Properly handling multiple constructors.
Peter Lind wrote: On 24 March 2010 15:33, Robert Cummings rob...@interjinn.com 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: [PHP] Properly handling multiple constructors.
The following code (which cannot currently work as PHP does not allow
for method overloading) would be perfect for me.
?php
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=ZEND002498r=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: [PHP] Properly handling multiple constructors.
On 24 March 2010 16:09, Robert Cummings rob...@interjinn.com wrote: Peter Lind wrote: On 24 March 2010 15:33, Robert Cummings rob...@interjinn.com 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
Re: [PHP] Properly handling multiple constructors.
Peter Lind wrote: On 24 March 2010 16:09, Robert Cummings rob...@interjinn.com wrote: Peter Lind wrote: On 24 March 2010 15:33, Robert Cummings rob...@interjinn.com 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: [PHP] 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.
?php
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: [PHP] Properly handling multiple constructors.
On 24 March 2010 16:23, Robert Cummings rob...@interjinn.com wrote: Peter Lind wrote: On 24 March 2010 16:09, Robert Cummings rob...@interjinn.com wrote: Peter Lind wrote: On 24 March 2010 15:33, Robert Cummings rob...@interjinn.com 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
Re: [PHP] Properly handling multiple constructors.
On 24 March 2010 15:27, Robert Cummings rob...@interjinn.com 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=ZEND002498r=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: [PHP] 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: [PHP] Properly handling multiple constructors.
Richard Quadling wrote:
On 24 March 2010 15:27, Robert Cummings rob...@interjinn.com 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: [PHP] Properly handling multiple constructors.
On 24 March 2010 16:48, Robert Cummings rob...@interjinn.com 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 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. 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 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. 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 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. 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
Re: [PHP] Properly handling multiple constructors.
On 24 March 2010 15:51, Robert Cummings rob...@interjinn.com 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=ZEND002498r=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: [PHP] Properly handling multiple constructors.
Peter Lind wrote: On 24 March 2010 16:48, Robert Cummings rob...@interjinn.com 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: [PHP] Properly handling multiple constructors.
On 3/24/10 11:06 AM, Richard Quadling wrote:
On 24 March 2010 15:51, Robert Cummingsrob...@interjinn.com 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
