Singleton Slinging
updated 5 months ago; latest suggestion 4 months 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.
Suggestions
-
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.
-
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.
-
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?
-
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!
-
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.