Re: RFC: User subroutine hinting interface for autodie

pjf,
So, my question to you, dear monks, is can I do this better? Can the hints be given better names? Is my set_hints_for method particularly unintuitive? How would you expect this to work?

I doubt I will ever use autodie so take that into consideration in reading the rest of my response.

use Some::Module qw(foo);
use autodie::hints;

autodie::hints->set_hints_for(
    \&foo,
    qw( LIST_EMPTY_OR_FALSE   SCALAR_UNDEF_ONLY )
);
[download]

What exactly am I setting? Is there an implied "The following list are failure indications"? In other words, would a more intuitive interface be sub => \&foo, fail => qw//?

You mentioned the issue was context - have you considered other contexts (Want and/or Contextual::Return) - lvalue subs could be interesting?

What about letting the user define a new hint. Let's say I have a function that returns a SQL code. Some of these codes are errors and some of them aren't but only a lookup table will allow me to define this. Perhaps someone wants to duplicate system and have anything other than 0 indicate failure.

Cheers - L~R

Comment on Re: RFC: User subroutine hinting interface for autodie Select or Download Code

Replies are listed 'Best First'.
Re^2: RFC: User subroutine hinting interface for autodie by pjf (Curate) on Mar 05, 2009 at 12:54 UTC
What exactly am I setting? Is there an implied "The following list are failure indications"? In other words, would a more intuitive interface be `sub => \&foo, fail => qw//`? My apologies for the lack of clarity in my original post. This is indeed an implied "here are a list of failure indications", as autodie's job is to throw exceptions automatically on failure. [What about] Want or Contextual::Return? I can say straight up that subroutines that use `Want` or `Contextual::Return` may cause headaches in combination with `autodie`. Those modules do very clever things when it comes to examining context, and autodie's intercept-and-inspect code may result in subtle changes. Autodie can't leverage their cleverness in any useful way, since (with one exception) it promises not to muck with a subroutine's return value(s). What about letting the user define a new hint. Let's say I have a function that returns a SQL code. Some of these codes are errors and some of them aren't but only a lookup table will allow me to define this. Yesterday, my response would be that this is beyond the scope of what `autodie` is intended to do, which is fundamentally remove the need to write `or die...` after far too many subroutine calls. Today, after receiving a wonderfully in-depth e-mail from TheDamian, I'm fairly convinced that people will still try and use `autodie` for situations like you've just described, which has had me do a lot more thinking about what hints are applicable. While I don't have everything in concrete yet, you can expect the final hints interface to allow one to pass a subroutine reference that can inspect the return and indicate if an exception should be thrown. That covers the situation of checking SQL return values in a table, or having subroutines that only fail if it's raining. Many thanks again for the feedback and thoughts, Paul Fenwick Perl Training Australia	[reply]

Replies are listed 'Best First'.

Re^2: RFC: User subroutine hinting interface for autodie
by pjf (Curate) on Mar 05, 2009 at 12:54 UTC

What exactly am I setting? Is there an implied "The following list are failure indications"? In other words, would a more intuitive interface be sub => \&foo, fail => qw//?

My apologies for the lack of clarity in my original post. This is indeed an implied "here are a list of failure indications", as autodie's job is to throw exceptions automatically on failure.

[What about] Want or Contextual::Return?

I can say straight up that subroutines that use Want or Contextual::Return may cause headaches in combination with autodie. Those modules do very clever things when it comes to examining context, and autodie's intercept-and-inspect code may result in subtle changes. Autodie can't leverage their cleverness in any useful way, since (with one exception) it promises not to muck with a subroutine's return value(s).

What about letting the user define a new hint. Let's say I have a function that returns a SQL code. Some of these codes are errors and some of them aren't but only a lookup table will allow me to define this.

Yesterday, my response would be that this is beyond the scope of what autodie is intended to do, which is fundamentally remove the need to write or die... after far too many subroutine calls.

Today, after receiving a wonderfully in-depth e-mail from TheDamian, I'm fairly convinced that people will still try and use autodie for situations like you've just described, which has had me do a lot more thinking about what hints are applicable.

While I don't have everything in concrete yet, you can expect the final hints interface to allow one to pass a subroutine reference that can inspect the return and indicate if an exception should be thrown. That covers the situation of checking SQL return values in a table, or having subroutines that only fail if it's raining.

Many thanks again for the feedback and thoughts,

Paul Fenwick
Perl Training Australia

[reply]