jepri has asked for the wisdom of the Perl Monks concerning the following question:

I've whipped up a OO system, and I have a way for the user to provide callbacks (many different ways, but anyway...). What parameters, and in what order, are the most convenient for users?

I've written an app using my toolkit, and at the moment, the order is:

Can anyone suggest things that I'm missing, or what would be more convenient?

____________________
Jeremy
I didn't believe in evil until I dated it.

Replies are listed 'Best First'.
•Re: Parameters for object callback
by merlyn (Sage) on Nov 06, 2002 at 04:39 UTC
    Take a look at how HTML::Parser defines callbacks. Basically, you create a callback specifying a simple text string giving what you want in the callback.

    If your library builds a closure based on the user-supplied string, it could be quite fast.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Re: Parameters for object callback
by jdporter (Paladin) on Nov 06, 2002 at 03:50 UTC
    With such a complex interface, it's hard to imagine any argument order being any better than any other.

    That said, the one criterion that one ought to keep in mind when deciding on argument order is:
    What arguments might reasonably be omitted?

    The one argument that could be omitted should be the last one.
    The two arguments that could be omitted should be the last two.
    And so on.

      I was trying to think of how my users might use it, but realistically I'm not going to be able to. So I guess its onto user testing and see what they say

      Thanks.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

Re: Parameters for object callback
by jdporter (Paladin) on Nov 06, 2002 at 14:07 UTC
    Another possibility to consider is named arguments.

    Perl supports this easily by having your sub construe the argument list as "hash-like". That is, instead of     my @args = @_; you could say     my %args = @_; Then the caller could do something like

    func( value => $obj_value, object => $obj, top => $top_node, affected_objects => { .... }, );
    With this scheme, it is easy to have any arguments be optional, rather than having to rank their "optionalness" as in the scheme I suggested above.