How to raise warning?


(Gavri Savio Fernandez) #1

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 :frowning:
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


(Mark Hubbart) #2

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.
I second that. Adding an optional boolean argument to the function to
get different results doesn’t quite seem rubyish to me.

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 :frowning:
There doesn’t seem to be any clue in their names to differentiate
their functionality from each other.

How about:
warn "Server timed out. retrying."
warn! “That number seemed a bit high… Possible error.”

This would keep the old behavior for warn(), but add a new function
warn!(), which would be used for more serious warnings where you want
to include a traceback.

-Mark

···

On Feb 19, 2004, at 11:50 PM, Gavri Savio Fernandez wrote:


(David A. Black) #3

Hi –

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.
[…]
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

I would love to see every case of boolean arguments (like
"methods(true)") disappear from Ruby – for exactly the reason you’ve
given, namely that they’re hard to understand and remember. I’ve
always thought they should be split into separate methods.

David

···

On Fri, 20 Feb 2004, Gavri Savio Fernandez wrote:


David A. Black
dblack@wobblini.net


(Robert) #4

“Mark Hubbart” discord@mac.com schrieb im Newsbeitrag
news:4A25FA2C-637E-11D8-9977-000502FDD5CC@mac.com

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.
I second that. Adding an optional boolean argument to the function to
get different results doesn’t quite seem rubyish to me.

It’s generally considered bad to have an interface method that changes
it’s behavior dependend on a flag. The typical solution is to have two
methods for the job. If they have something in common they can use a
private method for the implementation.

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 :frowning:
There doesn’t seem to be any clue in their names to differentiate
their functionality from each other.

How about:
warn "Server timed out. retrying."
warn! “That number seemed a bit high… Possible error.”

This would keep the old behavior for warn(), but add a new function
warn!(), which would be used for more serious warnings where you want
to include a traceback.

Ops, didn’t read your post before I send mine. Similar thoughts. :slight_smile:

Kind regards

robert
···

On Feb 19, 2004, at 11:50 PM, Gavri Savio Fernandez wrote:


(HAL 9000) #5

Mark Hubbart wrote:

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 :frowning:
There doesn’t seem to be any clue in their names to differentiate
their functionality from each other.

Agreed. Clear in my mind, but that probably says more about my mind
than about the syntax. :slight_smile:

How about:
warn "Server timed out. retrying."
warn! “That number seemed a bit high… Possible error.”

This would keep the old behavior for warn(), but add a new function
warn!(), which would be used for more serious warnings where you want to
include a traceback.

I like Mark’s idea better than mine.

Hal

···

On Feb 19, 2004, at 11:50 PM, Gavri Savio Fernandez wrote:


(Andrew Johnson) #6

Well, it’s certainly not unprecedented in Ruby:

Range.new(start, end, exclusive=false)
load(filename, wrap=false)
obj.respond_to?(symbol, include_private=false)
obj.private_methods(all=true)
obj.protected_methods(all=true)
obj.public_methods(all=true)

regards,
andrew

···

On Fri, 20 Feb 2004 17:25:17 +0900, Mark Hubbart discord@mac.com wrote:

I second that. Adding an optional boolean argument to the function to
get different results doesn’t quite seem rubyish to me.


(Charles Comstock) #7

Andrew Johnson wrote:

I second that. Adding an optional boolean argument to the function to
get different results doesn’t quite seem rubyish to me.

Well, it’s certainly not unprecedented in Ruby:

Range.new(start, end, exclusive=false)
load(filename, wrap=false)
obj.respond_to?(symbol, include_private=false)
obj.private_methods(all=true)
obj.protected_methods(all=true)
obj.public_methods(all=true)

regards,
andrew

Right but not in things that print strings, the precedent there is not
to use a boolean argument, since often you want to print multiple
things. I like the warn! idea though. I would however say, that this
is the classic use of a macro. Most other uses of macro’s we can
replace with a call to eval. But we lose the ability to do inplace code
expansion which is so important for LINE and things like that. That
and there is a way in C that you can get something to print out the name
of the variable. So you can have a macro that say:
v = 5

but your macro just says DEBUGV(v);

It seems like we might be able to do something like that with a symbol,
but I haven’t figured out how.

Charlie

···

On Fri, 20 Feb 2004 17:25:17 +0900, Mark Hubbart discord@mac.com wrote:


(Mark Hubbart) #8

Since there were a few good responses on a Kernel.warn!() method, I
decided to write up an RCR for it. It can be viewed here:
http://rcrchive.net/rcr/RCR/RCR219

Please comment on it! :slight_smile: Constructive criticism is very welcome.

cheers,
Mark