> From: Hal Fulton [mailto:hal9000 / hypermetrics.com]
> Subject: Re: how to raise warning?

> > Having a variant of 'warn' that displays that information 
> would be nice IMO.
> > 
> >   warn "You didn't provide such and such", true
> 
> Mmm. I would expect that just to print 'true' after the warning.
> 
> The problem as I see it is that we use warnings in two ways:
> 1. As Ruby does, to complain about something happening at a specific
>     place in the source -- a highly source-related message. In that
>     case, I'd want to see file/line info (as Ruby does when it says I
>     need to add parens or something).
> 2. To complain about some general condition occurring at runtime that
>     doesn't warrant bailing out of the app.
> 
> My suggestion: Two names. Call the first one "warning" (the kind of
> warning that Ruby gives us) and the second one "warn" (a simple verb
> that just prints to stderr).

One of the main things I like about Ruby is that the names are so intuitive.
Once i check out a particular class or method in the reference, it is pretty much guaranteed that i won't forget it ever. Even better, sometimes i just guess what the name of a particular entity might be, type it in and the program runs. This, for me, is a major plus for ruby.
Even if a particular name is esoteric, it is esoteric in a way i remember and find difficult to forget.

Okay, what i'm driving at is this: Naming one method 'warn' (A verb. I like that) and another 'warning' (A noun. Don't like it much) is quite confusing :(
There doesn't seem to be any clue in their names to differentiate their functionality from each other.

Maybe there's a better way than Gavin's proposal (more mnemonic names like 'warn_with_sourceinfo'. i know this name sucks but you get the idea) but for now i prefer it his way:
warn "You didn't provide such and such"
warn "You didn't provide such and such", true


> Hal

gavri