Class#name override causes ArgumentError when iterating classes

[amkisko]

Description

When calling klass.name on Faker::Travel::Airport (and potentially other Faker classes), an ArgumentError is raised because the method requires keyword arguments (:size and :region) that are not provided.

This breaks the standard Ruby behavior where Class#name should return the class name as a string.

Steps to Reproduce

require 'faker'

# This should return "Faker::Travel::Airport" but raises ArgumentError
Faker::Travel::Airport.name
# => ArgumentError: missing keywords: :size, :region

Expected Behavior

Faker::Travel::Airport.name
# => "Faker::Travel::Airport"

Actual Behavior

Faker::Travel::Airport.name
# => ArgumentError: missing keywords: :size, :region

Impact

This affects any code that:

• Iterates over classes using ObjectSpace.each_object(Class)
• Calls klass.name expecting standard Ruby behavior
• Uses metaprogramming that relies on Class#name

For example:

ObjectSpace.each_object(Class) do |klass|
  name = klass.name  # Raises ArgumentError when klass is Faker::Travel::Airport
  # ...
end

Environment

• Ruby version: 3.4.7
• Faker version: 3.5.2
• OS: macOS

Suggested Fix

The Faker gem should ensure that:

1. The class method name returns the class name string (standard Ruby behavior)
2. Instance methods that generate fake data use different method names (e.g., airport_name instead of name)
3. If the class method must be overridden, it should properly delegate to Module#name

Workaround

Calling code can wrap klass.name in error handling, but this is a workaround for a bug in Faker:

begin
  name = klass.name
rescue ArgumentError, NoMethodError, NameError
  next
end

[stefannibrasil]

Ah, good catch! thanks for reporting this.

We have 28 generators with name methods.

Are you interested in helping with this? To fix it, we'd need to deprecate these 28 methods in favour of other synonyms/words that make sense. Some of them could be renamed to nickname, full_name, etc., for example.

[thdaraujo]

This is not a bug, it has been the default behaviour for many of these generators for the past 18 years or more.

Have you considered filtering Faker classes out of your script?

ObjectSpace.each_object(Class) do |klass|
  next if klass.to_s.start_with?("Faker")
end

[amkisko]

@stefannibrasil Hey! I started this thread as it requires discussion and might become quite hot, thanks for asking, clearly understanding that it will require major version bump in order to clear this type of violation.

@thdaraujo Hey! The point is clear, for this type of library it might be okay as probably there was no intention to use it in production and only in development/testing environments (actually I guess not much people explore ObjectSpace in production), so it's kinda safe, but in the same time this type of practices seem to be offensive as they affect standard library behavior (ruby core).

I assume this as quality problem and possibility for the future to figure out better interface that won't clash with ruby core.

This might be also considered as a good honeypot as it will hit this type of exception anyways when source code is not known and in the same time implementing complex security scanner will demand exception for Faker library. Tricky!

[stefannibrasil]

Yeah, I spoke too soon. Updating 28 generators now would be too much. We haven't had any issues yet, besides this report, so it wouldn't justify making this change.

It's true it violates Ruby's core behaviour but those generators have been live for more than a decade now, and there's a workaround for navigating that. If we ever get to revisit this, it'd be for a more pressing need.