In Ruby, the typical way to define a class is using the class keyword:

Ruby

1

2

3

classFoo

# ...

end

The class keyword, however, is effectively just syntax sugar for the Class constructor:

Ruby

1

2

3

Foo=Class.new

# ...

end

Using Class.new is occasionally preferable, e.g. when you want an anonymous class which isn’t assigned to a constant:

Ruby

1

2

3

@myclass=Class.new

# ...

end

I like to use this technique for certain metaprogramming tasks, and when testing/spec-ing modules:

Ruby

1

2

3

4

5

6

7

8

9

10

describeMyModule

before:eachdo

@test_class=Class.newdo

includeMyModule

end

end

# ...

end

There are a few subtle semantic differences between the class keyword and Class.new. Because the Class constructor uses a block to define the contents of the class, it can reference the surrounding lexical scope:

TT

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

>> method_name = "foo"

=> "foo"

>> class KeywordClass

>> define_method(method_name) do

?> puts "hello"

>> end

>> end

NameError: undefined local variable or method `method_name' for KeywordClass:Class

from (irb):3

>> DynamicClass = Class.new do

?> define_method(method_name) do

?> puts "hello"

>> end

>> end

=> DynamicClass

>> DynamicClass.new.foo

hello

=> nil

I’d known about this difference for a long time. The other day I came across another difference between these two methods of class definition which was new to me, and can lead to potentially surprising behavior. It concerns the order of execution and the .inherited() callback.

When a parent class defines a class method called inherited:

Ruby

1

2

3

4

5

classA

defself.inherited(other)

puts"in A.inherited"

end

end

And then that class is subclassed:

Ruby

1

2

3

classB<A

puts"in class B body"

end

The order of execution is 1) run the A.inherited callback; then 2) execute the class definition body. You can see this if you run the above two blocks; the output will be:

TT

1

2

in A.inherited

in class B body

If, however, we try to inherit from A dynamically, using the Class constructor:

Ruby

1

2

3

C=Class.new(A)do

puts"in class C body"

end

The output is reversed:

TT

1

2

in class C body

in A.inherited

I’m not sure if either of these behaviors is right or wrong, per se; but it can catch you by surprise if you are expecting dynamic class definition to have the same order of operations as the keyword form. In particular, it can lead to some confusing side effects when using certain libraries that extend the behavior of Ruby’s classes. For instance, I discovered this difference while working on some code that used the class-inheritable attributes feature of ActiveSupport:

Ruby

1

2

3

4

myclass=Class.newdo

class_inheritable_accessor:bar

self.bar=42

end

TT

1

2

3

>> myclass.bar

=> nil

>> # hey! where'd the value of bar go?!

As it turns out, class_inheritable_accessor and its friends work by defining Object.inherited to initialize some variables that ActiveSupport uses for bookkeeping. In the dynamic form of the class definition, the class body would assign values to the inheritable attributes – and thenObject.inherited would be called back, re-initializing the variables and wiping out my assigned values. The solution was to separate the class creation and definition into two steps:

Ruby

1

2

3

4

5

myclass=Class.new

myclass.instance_evaldo

class_inheritable_accessor:bar

self.bar=42

end

So there you go, another, lesser-known semantic distinction between “static” and “dynamic” class definition in Ruby.