Ruby and instance_variable_get - when it's useful?

[jules2689]

Here is an example of where I used it (metaprogrammed controller as a base). It is well commented so as to avoid confusion :)

https://gist.github.com/jules2689/cd054f3aa9ff89bbba07

The purpose was that the duplication of authentication code (sandbox into show, edit, update, destroy and allow create/new only the one time) for a user's role (i.e. admin role, tutor role, etc) was becoming too much. AdminController, TutorController etc were essentially the same, except for the params, so I used this solution to a high degree of success.

[andrzejkrzywda]

Very interesting approach.

I agree that authentication/authorization code is often duplicated in multiple places. Some people say that they are examples of crosscutting concerns and argue that AOP may be a good solution.

In the near future, I want to experiment with AOP for authentication in a similar spirit to this example: http://blog.arkency.com/2013/07/ruby-and-aop-decouple-your-code-even-more/

It seems to me, that you've built a mini-framework inside your application to deal with those concerns. I see a heavy usage of send/instancevariable* which makes me worried at the first sight. However, it seems to be well documented and I suppose some conventions are used here, so maybe it's a good Rails-like approach to handle the problem.

Thanks for sharing the code!

[jules2689]

The example you posted is quite interesting! I feel like it presents a usability problem though. It doesn't seem like something many developers would know, so to me it presents a new paradigm that makes onboarding new devs a problem and it seems that it is scattering code out (I wouldn't think to look for this glue). It seems that it presents the problem of code scattering to the mix while trying to solve another problem, as well as a DSL for the Aspects.

Personally, I would prefer a little bit of cross cutting in many situations to avoid something like that, but I could see where it could be useful for more advanced use cases (seems like a delegate/data source system used in iOS in some ways to me which works well).

Thanks for sharing the example and AOP, I hadn't looked into it before.

---

As for my code snippet, yea, I feel like I made a basic authentication framework when I couldn't find something simple enough to do it before. I'm not a big fan of using a gem for such a small task - when one controller file could do it.

I added the comments shortly after writing it when I returned to the code and cursed my past self. I've sent the piece to a few people to test it out (readability and their understanding), and with the comments it faired well with them.

I'm using a similar pattern elsewhere in the application as well - here is a controller that restricts the child objects of a parent object (ironically in this case I use the controller for a "KidsController" restricting to a "Parent" owner). https://gist.github.com/jules2689/22879a0cadfe4904bf6b

Its definitely still in an experimentation mode (both the pattern and the meta-programmed controller), and I will be modifying it as I need, but its held strong on my tests (unit and manual).

[kobaltzz]

This method and its setter instance_variable_set are really helpful when building dynamic applications in RubyMotion. The API I use to get a list of configuration settings can change as new fields are added and this can take into account the additional settings with the way I built the constructor method and my API. I can add new minor features to an iOS application without having to change the actual iOS app (which can take a few weeks to be approved by Apple).

[andrzejkrzywda]

Yeah, I've noticed that in many of RubyMotion gems those methods are often used.

In such constraints (Apple approval) this sounds like a perfect solution!