On Sat, 2005-12-17 at 17:27 -0800, Darren Duncan wrote:
> 3. A flag that says we know that some operation failed, such as would
> be exploited in the "<failing-expr> err <deal-with-it-or-die>"
> situations.
> This concept is like an exception which isn't thrown but returned.
"Dropping" an exception, perhaps? :)
> 1. I accept the proposal that we just make another class that
> implements the SQL concept of a null value, perhaps named Null or
> SQL::Null, rather than having this behaviour in the core language, so
> that should simplify the rest of the discussion. If someone wants
> undefs to propagate through expressions like SQL's NULLs do, rather
> than failing or defaulting, then this can be done with the new class.
> A Null object would be defined but false. It would overload standard
> operators so that most expressions involving it would propagate a
> Null object, or compare unequally as desired. Therefore, this sort
> of behaviour will be isolated and standard data types won't behave
> this way by default.
I think this is out of scope; if a module chooses to use "undef" as a
well defined part of its interface, that's its call.
> 2. Modify the 'Exceptions' section of S04 so that built-in functions
> return a 'error' or 'failure' or 'exception' if they fail, instead of
> an "interesting value of undef". The behaviour and handling of or
> response to these is essentially unchanged, but the value is called
> something more distinctive and it is not called 'undef'. Instead of
> testing for .defined(), invoke a different method like .failed() or
> .error() instead; invoking .defined() on an error should perhaps
> return true instead of false. Perhaps update err() to activate on
> the error rather than or in addition to undef.
I'm not sure what this adds. You ask for a system call, you don't get a
result. In other words, the result is undefined, and it has a
supplemental error.
It just seems a bit silly to make the "err" operator have to call *two*
methods in sequence, it would be a hack just for system calls.
Besides, aren't all these values just "undef but { .error = '...' }"
etc?
> 3. Have the functionality of 'use fatal' turned on by default in
> large programs, though not one-liners, and it can be turned off
> otherwise. It is safer to have them brought to your attention where
> you make a conscious effort to respond to or dismiss them.
>
> 4. An expression or statement having an 'err' would impose a
> try-block around the expression it is attached to, so the right thing
> still happens when errors are thrown by default. And 'err' is a
> conscious effort to deal.
>
> 5. Autovivification in larger programs should not happen by default,
> unless you have something like 'use autovivify;'. But with
> one-liners it would work by default.
>
> 6. Attempts to use undef where a defined value is expected, such as
> wherever they currently generate warnings, should be upgraded to a
> stricture and fail by default in larger programs. But like with
> other strictures, this would be turned off by default in one-liners.
> If the DWIM behaviour is wanted in larger programs, one can say 'no
> strict undefs;' or such.
I think we need to be very careful not to impose too many good practice
measures on the developer. All of the situations you describe (except
perhaps autovivification) can potentially be picked up by the compiler,
and warnings generated.
> There may be remaining holes in my suggestions, but hopefully I dealt
> with the worst ones from the preceeding first draft.
FWIW, I didn't read the first thread.
Sam.
