DevHeads.net

How does the class name magic with Class.new?

This seems like deep magic... Any idea how it works?

a = Class.new
=> #<Class:0x0000558d34f68b48>
It seems as if whenever you create a Constant it checks to see to see
if it is an unnamed class and then names it....

That seems..... too magic.

Comments

Re: How does the class name magic with Class.new?

By Ryan Davis at 06/11/2019 - 06:47

You might want to stop using ruby

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Re: How does the class name magic with Class.new?

By Kevin Deisz at 06/11/2019 - 09:28

I hope you're joking Ryan, because otherwise you're implying that healthy
skepticism isn't welcome in the ruby community, and that if you're looking
to more deeply understand the internals of how ruby works you should just
stop.

This kind of attitude is why a lot of programming communities suffer from
gatekeeping. Please don't do that to ruby.

Re: How does the class name magic with Class.new?

By Matthew Kerwin at 06/10/2019 - 00:03

Yeah, no, that's pretty much exactly how it works.

On Mon, 10 Jun 2019 at 13:51, John Carter <john. ... at taitradio dot com> wrote:

Re: How does the class name magic with Class.new?

By John Carter at 06/10/2019 - 00:27

I tried digging about the ruby source code to spot where the magic
happen and/or find the documentation on const_set that says it's magic
and that magic can be relied on....

..no luck so far.

Any pointers as to exactly where that magic is implemented?

On Mon, Jun 10, 2019 at 4:03 PM Matthew Kerwin < ... at kerwin dot net.au> wrote:

Re: How does the class name magic with Class.new?

By Matthew Kerwin at 06/10/2019 - 02:17

In variable.c, check rb_const_set

It's definitely a spec.

On Mon, 10 Jun 2019 at 14:29, John Carter <john. ... at taitradio dot com> wrote:

Re: How does the class name magic with Class.new?

By Xavier Noria at 06/10/2019 - 02:34

The class keyword does the same behind the scenes, it creates a class
object and assigns it to a constant. The name is set as a side-effect just
like you saw doing it by hand.

It's interesting to note that there is no API to manipulate this name, but
at the same time the name is independent of the constant from that point
on. Indeed, you can even remove the original constant, and the name of the
class is still "C":

irb(main):001:0> C = Class.new
=> C
irb(main):002:0> C.name
=> "C"
irb(main):003:0> D = C
=> C
irb(main):004:0> Object.send(:remove_const, :C)
=> C
irb(main):005:0> D.name
=> "C"
irb(main):006:0> D
=> C

Besides, if you reopen D, you are reopening the class with name "C", because

class D
end

is not about the constant you see in the listing, Ruby checks if the
constant is defined, and if so it *reopens the class object it contains*,
regardless of its name. You reopen class objects, not constants.

This connection and disconnection class/module objects vs constants makes
constants a topic full of non-intuitive technical possibilities if you're
only used to the golden path in which all matches.

That is why Zeitwerk requires a certain project structure and basically
restricts things to that golden path, by limiting what you can do, it makes
autoloading solvable.