This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Ruby object model: A matter of life and death

updated over 7 years ago; latest suggestion over 7 years ago

In ruby everything is an object, yes... but what kind of object? Is there only one kind of object? Is every object treated the same way by ruby?

What is really happenning when you are extending a module, or including another one? What is that about singleton classes? What are the differences between instance and class variables?

There is some stuff in ruby which we may have been using for a long time -or not so long, maybe- but have not always fully understood. With this talk I would try to draw the roadmap through the ruby object model, so you can walk through your application classes confident, easy and with no pain.

I would focus on the ruby 1.9 mri implementation, since it is the reference, but the principles should remain in every other implementation.


  • The proposal author responds over 7 years ago

    Hi Murray,

    Thank you very much for your thoughts. The idea behing this talk, is that everyone can understand modules such as ActiveSupport::Concern.

    I can not even think how I was able to write any code without knowing the ruby object model properly :-P

    And speaking about tongue twisters I like very much this one from Paolo Perrota: "The superclass of the eigenclass of an object is the object's class. The superclass of the eigenclass of a class is the eigenclass of the class's superclass" XD

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 7 years ago

    I think a clear and simple discussion of the object model would be of great benefit to even the most battle-hardened rubyist. Something like ActiveSupport::Concern extends the basics of the object model to prevent some weird edgcases - I think it would be good if we were to come away understanding exactly what those were and why/how it gets around them. Not that I want to turn this into a rails talk, but I think it's an example of object-model weirdness that most people will have seen.

    ps. Good luck writing this in a way that means you don't have to say "Class is an object whose class is Class", and ending up just saying "class" over and over and over.... :)