It is a little easier to modify the arguments independently of the subroutine to be called, at the cost of a more complex data structure and more complex subroutine calls.

One way this could be done, as the subroutine is called, is as follows:

$menu_hash{1}{sub}->({
    %{$menu_hash{1}{args}},      # default arguments/values
    ifc_default => 'overridden', # override default value
    ifc_color => 'green',        # add an argument/value
});
[download]

There would be no point including the arguments hash from $menu_hash if, as in this case, it included only one element which was being overridden, but it could have other elements, only some of which are overridden in a given call.

The arguments could be set or changed independently of either setting or calling the subroutine to be called.

Whether these are advantages or not will depend on the situation. The name 'ifc_default' suggests that there might be situations where non-default arguments might be passed.

But I think I like the method LanX suggested better than my own, now that I think about it.

update: and then I realized that what your suggested is very similar to what LanX suggested, and additional/override arguments can easily be included in your approach.

"1" => sub { get_ifc_name({'ifc_default' => 'test_me', %{shift} }) },
[download]

after which

$menu_hash{1}->({ifc_default => 'overridden', color => 'green'});
[download]

So, after all, I like my own suggestion least of all. Thanks for questioning it.

and additional/override arguments can easily be included in your approach.

"1" => sub { get_ifc_name({'ifc_default' => 'test_me', %{shift} }) },

don't you think that an explicit currying function like setdefaults(), is clearer, better maintainable, more DRY and scalable?

I supposed there are more than just one coderef to be parameterized.

And even if there is just one, IMHO the above "literal" code is not immediately understood by many coders... changed my mind it's not so obscure, if you only need one currying at all it might be better this way. :-)

Cheers Rolf

I see advantages and disadvantages in each alternative, leaving me quite ambivalent. They are close enough that I think it would be difficult to make a seriously bad decision between them.

Which implementation is clearer will depend on what the reader/developer is familiar with. I would have thought the "literal" code would be more easily understood but your initial reaction proves the point that what is clear is quite personal.

The currying function uses a closure which, conceptually, isn't trivial. Otherwise, there is little difference in the set of language features used. On this basis, I would say the currying function is a little less "clear". But, for those familiar with closures, I guess it is at least as clear.

The currying function allows the function and default arguments to be set with minimal clutter at the expense of "hiding" what is being done with the arguments in a "remote" block of code. Not much of a problem when that block is adjacent to the function call as in the example, but at least a slight impediment to easy understanding if they are at a greater distance.

I agree the currying function is more DRY. Also, if there are many functions being set, it makes it much clearer that they are all being handled in the same way. This clarity should improve scalability. This and the reduction of typing should improve maintainability. The significance of this advantage increases as the scale of the project (number of functions being set) increases.

Yet, there is also clarity and ease of maintenance in the terseness and immediacy of ikegami's implementation, particularly for smaller (fewer functions) projects.