Comments on: The “Multitype Parameter” Pattern

By: cakebaker

cakebaker — Thu, 16 Aug 2007 16:42:11 +0000

@Berry: Yes, you are right, it is a PHP-specific pattern.

By: Berry

Berry — Thu, 16 Aug 2007 07:42:43 +0000

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.

By: cakebaker

cakebaker — Tue, 26 Jun 2007 16:37:12 +0000

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

By: bododo

bododo — Tue, 19 Jun 2007 22:11:03 +0000

blesssed is python for its functions parameters syntax: named params, lists… :-)

By: Brandon

Brandon — Tue, 19 Jun 2007 16:47:11 +0000

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.

By: Geoff

Geoff — Tue, 19 Jun 2007 11:35:00 +0000

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

By: cakebaker

cakebaker — Tue, 19 Jun 2007 07:33:07 +0000

@all: Thanks for your comments.

By: Nate

Nate — Mon, 18 Jun 2007 15:54:29 +0000

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.

By: Grant Cox

Grant Cox — Mon, 18 Jun 2007 12:00:50 +0000

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.

By: JMG

JMG — Mon, 18 Jun 2007 11:38:29 +0000

I think you’re wrong : ‘controller’ and ‘action’ do have a meaning; ‘c’ and ‘a’… just don’t.