This post originated from an RSS feed registered with Ruby Buzz by Trans Onoma. Original Post: Meta du jour Feed Title: TRANSONOMA Feed URL: http://feeds.feedburner.com/transonoma Feed Description: A Light Green Agile Programming and SciTech Blog Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Trans Onoma Latest Posts From TRANSONOMA

So I'm coding in my usual modus operandi, meta-programming. And I start thinking, is it really right that objects themselves have the methods for "sneaking-in" under their walls? I mean, is it truly best that an object maintain it's own mechinisms of deviating from standard, non-meta practice? In particular I'm refering to those meta-programming staples instance_eval and class_eval. But there are a number of others too, like instance_variable_get, instance_variable_set and, I hanker to speculate, we may also soon have instance_send.

So why do I wonder about this? Well, I'm improving upon Jim Weirich's BalnkSlate, and in so doing it's became clear that some additional methods must remain. It already held on to all the __xxx__ mehtods, but responds_to? turns out to be a good keeper. I've also added __class__, __clone__ and __self__ which all prove useful --pretty straight foward really and I think these would serve well in Object's core. But the methods one doesn't initially consider are those instance_xxx methods. They turn out to more necessary then one might expect. Yet adding __instance_xxx__ here doesn't do any good really --they are already meta-programming methods, just with out the underscores.

It isnt' a hard jump to thik that perhaps instance_eval ought to be the domain of Kernel, since eval is alread y there. and just as eval is able to eval in the context of a binding, why not also an object?

  eval %{ puts self }, anObject

That seems quite reasonable. It feels comfortable actually to meta-program like this from the outside the object, rather then intricate to it. No doubt there are some thing to work out --differentiation between class_eval and instance_eval for example. But that's a minor detail.

From here, I wonder how far this extends. Is responds_to? a meta-programming method? Should that have a place seperate from object too? Its not far fetched. The criteria for determination is pretty clear: should the method be overridable? If not, the bet is it's a meta-method.

So here's an idea. Create a core module with the whole variety of useful meta-programming methods. Call it Meta or perhaps better Inspect.

  Inspect.class( obj )
  Inspect.self( obj )
  Inspect.clone( obj )
  Inspect.eval( obj ) { ... }
  Inspect.meta_eval( obj ) { ... }
  Inspect.var_get( obj, iv)
  Inspect.var_set( obj, iv, val)

It can also easily be wrapped to provide a module to be included into Kernel for backward compatability as needed.

I think such an approach would prove much cleaner and less problematic when handling the many interesting meta-usecases out there, from the simple class of BlankSlate to full blown testing facilities. I don't know if you know it, but meta-programming is a blast. Where once it was Lisp, now Ruby is the meta-programming language du jour.