Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: RFC: User subroutine hinting interface for autodie (terse, unhidden)

by tye (Sage)
on Mar 05, 2009 at 07:53 UTC ( [id://748448]=note: print w/replies, xml ) Need Help??


in reply to RFC: User subroutine hinting interface for autodie

I don't like the current hinting system nor your proposed improvement that hides the information and relies on a cabal to pre-compute the hints so that the unwashed masses never have to see it, know about it, or use it. I think such hidden information has a high probability to be incomplete and inconsistent such that users become very surprised why something works fine on one system and looks identical and doesn't work on some other system.

But I think you can greatly simplify the hints to the point that making them visible is not a burden.

I would define the following defaults:

  • In a scalar context, undef means failure.
  • In a list context, empty list means failure.

And I would define the following options:

  1. This function always returns just one scalar, even when used in a list context (represented by $, the sigil for scalar values in Perl 5)
  2. Empty string (including undef) means failure (represented by ", not only unambiguously "string"y in Perl but also visually similar to '', the empty string)
  3. 'False' means failure (represented by !, logical negation)

Then you can quite concisely represent any meaningful combination of those options:

use autodie qw( ReadLine Copy!$ NextKeyword! GetParam$ GetCount"$ Next +Word" );

Where ReadLine() returns an empty list on failure, undef in a scalar context. Copy() always returns a scalar which is simply false in the case of failure. A successful NextKeyword() returns either a non-empty list or (in scalar context) a string that is never '' nor '0'. GetParam() does return undef; on failure. GetCount() returns an empty string for failure. Finally, a successful NextLabel() returns either a non-empty list or (in scalar context) a string that is not ''.

As for pre-computing hints, I would require that the user request the pre-computed hint so that, if the current system lacks that particular hint, the user can be made aware of the problem. I'd probably use a '?' to indicate that the user doesn't claim to know the answer and asks that the module author provide it.

- tye        

Replies are listed 'Best First'.
Re^2: RFC: User subroutine hinting interface for autodie (terse, unhidden)
by pjf (Curate) on Mar 05, 2009 at 12:27 UTC

    Tye, this is excellent, and is exactly the sort of discussion and thoughts I was after. I really appreciate the feedback, even though I'm about to argue against most of it. ;)

    I agree that having secret hints is going to result in some bad surprises. Those surprises are going to especially bad when a production system lags behind the development system, and an otherwise correct piece of code suddenly and silently becomes incorrect. That's a really great argument for getting hints out in the open.

    However I don't think that users providing their own hints is a good idea. For starters, it means that users need to know much more about the subroutines they're using than they should. I shouldn't need to care about how File::Copy signals failure if I've delegated that task to autodie. I certainly don't want to provide hints every time I invoke the pragma, since that gives me extra chances to get them wrong.

    As a lazy consumer, what I do need to know is that when I've delegated something to autodie that it's up to the task. In this sense, I like your idea of using '?' or some other marker to indicate that hints should exist for a given subroutine; I can trigger a compile-time error if they don't.

    The other thing I can do is to have autodie insist that all autodying user subroutines have hints, and introduce a marker to indicate that a subroutine is allowed to use the defaults and be hint-free. I really like this, since it makes sure there are no surprises, and it keeps the common syntax both clean and safe. Unfortunately, it also breaks backwards compatibility with existing uses of the module. That's bad.

    In any case, a way of signalling that we must know hints for a user-sub is essential for any interface that autodie makes public.

    Thanks again for the input, it's hugely appreciated!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://748448]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-03-28 22:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found