The “Multitype Parameter” Pattern
One of the patterns you find throughout CakePHP is what I call the “Multitype Parameter” pattern (maybe there exists an “official” name for it, I don’t know). It allows you to either pass a string or an array as a parameter to a function. An example:
$this->redirect('/users/add');
or
$this->redirect(array('controller' => 'Users', 'action' => 'add'));
As usual in software engineering, using such a pattern comes with trade-offs. On the one hand you get a flexible interface you can extend very easily by adding new keywords, and which is handy for the user as in the usual case he can simply pass a string whereas in other cases he can pass an array. On the other hand you have to write more code and it becomes more difficult to override a method using this pattern.
I don’t use that pattern often in my own stuff, but maybe it will be helpful to you.
so wich one is the best ?
the second one seems more flexible,
the first one more lisible (perhaps the second one could be more readable with the use of ‘c’ instead of ‘controller’ and ‘a’ instead of ‘action’ ?
$this->redirect(array(’c’ => ‘Users’, ‘a’ => ‘add’));
or better, like this :
$this->redirect(array(’Users’ => ‘add’));
One of the purpose of Cake wasn’t to define conventions !
so lets define one for this case !
the 1.2’s production release can be the right moment for it !
Or I’m wrong ?
I think you’re wrong : ‘controller’ and ‘action’ do have a meaning; ‘c’ and ‘a’… just don’t.
Yes, being verbose in this case is more readable, not less - if you want it to be simple just use “/users/add” - use the convention that already exists.
As for the OP, I find the extensibility of array params to be very attractive (and I’ve been burned on an old project which ended up with stupid amounts of parameters due to feature creep over the years). But in the majority of cases it just seems “right” to use normal parameters - if you only think you need $user_id and $group_id, then having an array param is just overkill.
I can’t say that I ever support both cases like the Cake core - but then I’m not in the library / framework writing business. I certainly appreciate the work the core devs have done though - their hard work allows me to have simplicity / extensibility as I need it.
Well, I don’t think we really have a name for it, but “Multitype parameter” sounds good to me. ;-)
I’ve actually taken this a step further in several methods by allowing the omission of certain parameters, i.e. the model name as the first parameter to FormHelper::create(). If an array is passed as the first parameter, it is auto-interpreted as the second.
@JMG: Exactly. Lack of clarity it not a design goal of CakePHP.
@all: Thanks for your comments.
I like and have used the “multiple parameter” stuff quite a bit. It not that hard to support. It is very good for setting default settings and then only overriding the ones required. It is very similar to the way JQuery plugins take settings via a JSON object.
I think it produces cleaner code and adds to readability in the end, much nicer than heaps of nulls or false in a function call
The formal defining of parameters in functions is a convention that was created long before multi-dim arrays or objects were conceived.
IMO, I think the “multitype” design pattern is becoming more and more popular because of its extensibility and the overall trend of decreasing dependencies on strict data typing (i love you php!)
But, I definitely think this design should be used with caution. Especially in large projects where people rely on API’s to communicate functions roles.
One of the biggest issues I see is the issue of returning unexpected results. Since these types of function almost ALWAYS merge with default values.
blesssed is python for its functions parameters syntax: named params, lists… :-)
@Geoff, Brandon, bododo: Thanks for your comments.
@Brandon: Yes, it should be used with caution, but for methods like FormHelper::input() it is really handy.
It doesn’t have an official name, nor will it ever get one. The example you’ve shown will only work in PHP, because of the non-strict typing. Thus, it can never become an actual pattern. Nevertheless, in other languages overloading can be used, but that makes it overloading, nothing more, nothing less.
@Berry: Yes, you are right, it is a PHP-specific pattern.