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