Method Arguments. Should I?

Hi All,

I started writing some methods and along the line for some reason I
thought
it would be a good idea to have some flexibitily in the arguements that
the
method would accept.

Basically, I could have a string, a list of strings, an array of
strings,
or an array of AR Objects that the strings map to the name attribute.

this results in the ability to pass arguments like

( “one” )
(“one”, “two”, “three” )
( [“one”,“two”,“three”]’,[“a string”,[ object1, object2]] )

and so on

Basically I’m wondering if this is a good idea or should I make it a bit
more rigid in what arguments can be recieved.

Cheers
Daniel

Hi –

On Sat, 25 Nov 2006, Daniel N wrote:

( “one” )
(“one”, “two”, “three” )
( [“one”,“two”,“three”]',[“a string”,[ object1, object2]] )

and so on

Basically I’m wondering if this is a good idea or should I make it a bit
more rigid in what arguments can be recieved.

My rule of thumb for the optimal amount of flexibility, in most cases,
would be whatever is consistent with duck typing – that is, with
addressing the arguments uniformly and without branching on their
classes. That means I’d probably draw the line at the AR objects.

This approach tends to give you the most informative calling code,
because it does a reasonable amount of normalization up front. If
you’re mixing everything, as in your third example, and depending on
the method to unjumble it, then when you look at your calling code you
have to hold in your head the fact that various mappings take place,
and that becomes harder later on when it’s all less fresh in your
mind.

David


David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

On 11/25/06, [email protected] [email protected] wrote:

would be whatever is consistent with duck typing – that is, with
addressing the arguments uniformly and without branching on their
classes. That means I’d probably draw the line at the AR objects.

Ok That makes sense. I thought it was getting a little nasty.

This approach tends to give you the most informative calling code,

because it does a reasonable amount of normalization up front. If
you’re mixing everything, as in your third example, and depending on
the method to unjumble it, then when you look at your calling code you
have to hold in your head the fact that various mappings take place,
and that becomes harder later on when it’s all less fresh in your
mind.

I have seen that you don’t like to use flatten too much recently on the
list. Do you think it’s ok to allow nested arrays? I only need to get
a
list of all objects in it, so for my purpose, flattening the whole thing
down to a single array would be acceptable.

Thanx for your input
Daniel

Hi –

On Sat, 25 Nov 2006, Daniel N wrote:

My rule of thumb for the optimal amount of flexibility, in most cases,
the method to unjumble it, then when you look at your calling code you
have to hold in your head the fact that various mappings take place,
and that becomes harder later on when it’s all less fresh in your
mind.

I have seen that you don’t like to use flatten too much recently on the
list. Do you think it’s ok to allow nested arrays? I only need to get a
list of all objects in it, so for my purpose, flattening the whole thing
down to a single array would be acceptable.

Yes, I think flatten would be fine as a degree of normalization inside
the method, so that you could use a list or an array or some mixture.
This is a case where you’d want to flatten completely, not just by one
level. The problems with flatten arise mainly when it flattens too
much and demolishes arrays that should have remained arrays.

I do hope that flattenx[1] or equivalent makes it into Ruby 2.0.

David

[1] http://www.rubypal.com/ruby/flattenx


David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

Yes, I think flatten would be fine as a degree of normalization inside

the method, so that you could use a list or an array or some mixture.
This is a case where you’d want to flatten completely, not just by one
level. The problems with flatten arise mainly when it flattens too
much and demolishes arrays that should have remained arrays.

I do hope that flattenx[1] or equivalent makes it into Ruby 2.0.

Thanx for this insight David. Makes me feel much better about this
direction.

Cheers
Daniel