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

Singleton Slinging

updated about 4 years ago; latest suggestion about 4 years ago

Ruby is a truly dynamic language. You can, using metaprogramming techniques, modify any object at runtime. As everything is an object, this means you can do that to anything! Adding or removing methods, creating new classes, or even modifying single instances of a class. It's all very interesting, but how useful is it?

In this talk, we'll go through a brief lesson on dynamically modifying singular instances of a class, then move to a few examples of how this can be used to add new methods to an instance so that it can utilize ducktypes to work with interfaces a normal instance of its class could not. We'll also discuss why the benefits and drawbacks of this approach and how this could be used in a production environment to do things like: allowing unauthenticated users to have dynamic authorizations without creating database clutter, or utilizing the technique inside modules to allow pieces of a class (if they exist) to conform to additional class interfaces provided by the module.


  • Acd62030df551952268e84c8fff26a5b James Adam suggests about 4 years ago

    I'm particularly partial to a bit of meta-programming, but I think what can make or break presentations about it is the strength and coherency of their examples. Finding the sweet spot between triviality and comprehensibility would really make this presentation shine.

  • Be3698f145a80c1230fd667c87d0f0c8 Tom Stuart suggests about 4 years ago

    I’d like to hear this talk. For what it's worth, I didn't find the title confusing at all: since Ruby 1.9 added Object#singleton_class, we’re all agreed that this is what “metaclasses”/“eigenclasses”/etc are called, so in a Ruby context I’m much more likely to think of singleton classes than the Singleton pattern.

    In addition to its performance implications, I’d love to hear about how this language feature enables and/or interacts with techniques like DCI and Ruby 2.0’s refinements.

  • 9aad27c9b22345c079622758970e24ff Robert Chatley suggests about 4 years ago

    I agree with Paul that the title was a bit confusing. I expected a talk describing the (well-known) problems with singletons. This seems to be more about meta-programming, which is more interesting to me. Perhaps a change of title would help?

    I'd also like to get an idea of how common it is for Ruby programmers to actually do this - or is it something that you /can/ do, but no-one really does in production code?

  • The proposal author responds about 4 years ago

    I was planning to address the concerns of performance towards the beginning of the talk when discussing how to do this. The question of why one would do this anyways is one that comes later in the talk when discussing the potential examples.

    Thank you for the feedback!

  • 2abf5beb51d5d66211d525a72c5cb39d Paul Battley suggests about 4 years ago

    I was slightly confused by the title of this talk, as I usually associate the word singleton with the Singleton standard library module (and, I suppose, the pattern of the same name). That might just be me, though.

    I recall reading recently that modifying instances can be bad for performance, as it prevents the interpreter from using a cached method lookup table. I don't know how significant this is (it will depend on circumstances), but I'd hope to see this addressed and to see what advantages might make this cost nonetheless worthwhile.