Ruby Forum Ruby-core > [PATCH] error.c (Init_Exception): Rename class "fatal" to "Fatal"

Hi,

Since most other Ruby classes have a name with the first letter in
uppercase, I think "fatal" should be no exception.

Here's a patch for the 1.8 branch if you want, but the change itself is
very trivial.

  - Otto Hilska

Hi,

At Wed, 6 Aug 2008 20:16:00 +0900,
Otto Hilska wrote in [ruby-core:18145]:
> Since most other Ruby classes have a name with the first letter in 
> uppercase, I think "fatal" should be no exception.

Ruby scripts should not use it.

Nobuyoshi Nakada wrote:
> Hi,
> 
> At Wed, 6 Aug 2008 20:16:00 +0900,
> Otto Hilska wrote in [ruby-core:18145]:
>> Since most other Ruby classes have a name with the first letter in 
>> uppercase, I think "fatal" should be no exception.
> 
> Ruby scripts should not use it.
> 

It's still available for the scripts. For example, running in Rails
environment:

 >> Object.subclasses
SyntaxError: (eval):1:in `subclasses_of': compile error
(eval):1: syntax error, unexpected tIDENTIFIER, expecting tCONSTANT
defined?(::fatal) && ::fatal.object_id == k.object_id
                 ^
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/extending.rb:15:in
`subclasses_of'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/extending.rb:13:in
`eval'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/extending.rb:15:in
`subclasses_of'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/extending.rb:13:in
`each_object'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/object/extending.rb:13:in
`subclasses_of'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/class/removal.rb:16:in
`subclasses'
         from (irb):1

There're some other cases too, where having a class with a lower-case
first letter can cause surprising effects. For me the problem was when
we were importing Ruby sources (and thus all classes) to apidock.com.

If 'fatal' should not be used in scripts, changing the name should not
cause compatibility issues either. So what are the reasons for keeping
it lower-case?

  - Otto

Hi,

At Wed, 6 Aug 2008 22:05:00 +0900,
Otto Hilska wrote in [ruby-core:18148]:
> It's still available for the scripts. For example, running in Rails 
> environment:
> 
>  >> Object.subclasses
> SyntaxError: (eval):1:in `subclasses_of': compile error
> (eval):1: syntax error, unexpected tIDENTIFIER, expecting tCONSTANT
> defined?(::fatal) && ::fatal.object_id == k.object_id
>                  ^

What do you mean by that error?

> If 'fatal' should not be used in scripts, changing the name should not 
> cause compatibility issues either. So what are the reasons for keeping 
> it lower-case?

`fatal' means the case that user scripts can't/shouldn't
raise/rescue it.

First, why and how do you need it?

On Thu, Aug 7, 2008 at 1:37 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> 
wrote:
>> defined?(::fatal) && ::fatal.object_id == k.object_id
>>                  ^
>
> What do you mean by that error?

It's a method which searches ObjectSpace for subclasses of a set of
superclasses. It may find some classes which have been remove_const
but not garbage collected, so this eval checks whether the class is
'live'.

The full method:

  # Exclude this class unless it's a subclass of our supers and is 
defined.
  # We check defined? in case we find a removed class that has yet to be
  # garbage collected. This also fails for anonymous classes -- please
  # submit a patch if you have a workaround.
  def subclasses_of(*superclasses) #:nodoc:
    subclasses = []

    superclasses.each do |sup|
      ObjectSpace.each_object(class << sup; self; end) do |k|
        if k != sup && (k.name.blank? || eval("defined?(::#{k}) &&
::#{k}.object_id == k.object_id"))
          subclasses << k
        end
      end
    end

    subclasses
  end


>> If 'fatal' should not be used in scripts, changing the name should not
>> cause compatibility issues either. So what are the reasons for keeping
>> it lower-case?
>
> `fatal' means the case that user scripts can't/shouldn't
> raise/rescue it.
>
> First, why and how do you need it?

It's not used purposefully. The script above assumes that every Ruby
class has a valid Ruby name. It seems a fair assumption.

Best,
jeremy

On Thu, Aug 7, 2008 at 15:48, Jeremy Kemper <jeremy@bitsweat.net> wrote:

> It's not used purposefully. The script above assumes that every Ruby
> class has a valid Ruby name. It seems a fair assumption.


Considering Module#name can be overridden and constants can be 
redefined, I
wouldn't rely too much on that assumption.

module A
  module AA; end
end

aa = A::AA

module B; end
A = B

puts aa.name

Daniel Luz wrote:
>> It's not used purposefully. The script above assumes that every Ruby
>> class has a valid Ruby name. It seems a fair assumption.
>>     
>
> Considering Module#name can be overridden and constants can be redefined, I
> wouldn't rely too much on that assumption.
>   

And there are anonymous modules:

% ruby -e'p Module.new.name' 
[2008/Aug/08(Fri) 10:16:55 JST][shyouhei][SZ92PS][pts/4][screen 2]
""

On Thu, Aug 7, 2008 at 6:23 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> 
wrote:
> Daniel Luz wrote:
>>> It's not used purposefully. The script above assumes that every Ruby
>>> class has a valid Ruby name. It seems a fair assumption.
>>>
>>
>> Considering Module#name can be overridden and constants can be redefined, I
>> wouldn't rely too much on that assumption.

It's definitely a fragile assumption. Maybe there's a better way.

> And there are anonymous modules:
>
> % ruby -e'p Module.new.name'                                                                                                                  [2008/Aug/08(Fri) 10:16:55 JST][shyouhei][SZ92PS][pts/4][screen 2]
> ""

Right; the code above skips anonymous classes.

'fatal' is exceptional because it's a named constant, responds to name
like any other class, but cannot be referenced in Ruby using its name.

This edge case happens to affect this obscure code. I don't think it's
a real issue :)

jeremy

Hi,

At Fri, 8 Aug 2008 03:48:39 +0900,
Jeremy Kemper wrote in [ruby-core:18174]:
> It's a method which searches ObjectSpace for subclasses of a set of
> superclasses. It may find some classes which have been remove_const
> but not garbage collected, so this eval checks whether the class is
> 'live'.
> 
> The full method:

ObjectSpace.each_object is ineffective, and Module#inherited
would be often more useful.  Still I don't understand why it is
needed.