Mixing Our Way Out Of Instance Eval?

mix_eval is the kind of thing I’d use all the time were it part of ruby core.

(by the way, is markaby is getting a makeover any time soon?)

Looks really neat, this could help clear up some of the weirdness you get with DSLs. Thankya!

This seems like it could also be an answer to the much-asked-for selector namespaces.

How does this relate: http://www.somethingnimble.com/bliki/mixology

Jim: It looks like mixico’s disable_mixin is identical to mixology’s unmix in the C extension. It just reverses what’s done in Ruby’s rb_include_module.

How wonderful! I had been fooling around with this sort of approach, except I was calling remove_method for each of a module’s methods. This is much cooler.

How well does this work in the presence of threads?

Hmmm … Actually, I’m thinking that this won’t work with builder because the builder object needs to remove methods (in order for method_missing to kick in) rather than add methods via a mixin. However, it might be useful in other contexts.

I also experimented with another solution to this problem. Instance eval the block in a director object that will try the method on both the builder and the containing object. Hopefully the director object can choose the right object (probably by giving proirity to one or the other). I decided against this because the solution seemed unnecessarily complex.

Jim Weirich: I actually think that further work on this should focus on masking methods so that the mixin could capture everything except the stuff that’s in BlankSlate or 1.9’s BasicObject.

This exercise may not have any answers in this incarnation. The specific idea is more about investigating the greys between the two extremes of instance_eval and regular blocks, in the hopes of leading us to something genuinely useful SLASH futuristic!

hi,
i totally agree, mixins have i great unexplored potential, we just should think more architecture than magic. I ran in this “unconscious self” problem as well and used a similar “uninclude” lib in : Refactoring rails exercise

If you get an exception in blk.call, it appears that you need to ensure the mixout is performed…

I am so going to start using mixico in my projects. I think this will become very important with ruby1.9, because now instance_eval impacts the lookup of constants in addition to instance variables.

I have been (and still am) heavily using instance_eval in SVuGy. I have been trying to understand where exactly the problems are, and why e.g. Jim Weirich has abandoned it in Builder. The explanation provided (“This is OK until you want to call a method in the calling object. Since self is no longer the calling object, you have to explicitly provide the caller.”) didn’t really cut it for me.

All the examples use tons of methods on the Builder objects, and
virtually none on the calling object. Actually, as long as you already have a local variable outside the Builder blocks, things should be fine. If you have to create a local variable because all you have is an instance variable, it’s more of a hassle, but I currently still think that it’s preferable to sprikling around tons of xm..

But having a mixin on/off system gives you the best of two worlds, so why not? Actually, there’s one more advantage: You don’t really want your users to access the instance variables of your implementation internals. And making the client’s instance variables available will hide the implementation-internal instance variables, if I understand correctly.

This is too late for 1.9, but I hope it will go into 2.0, in one shape or another.

IMHO the method has two issues:

1. return value is lost
2. no exception safety

So, I’d rather do

 class Module
   def mix_eval mod, &blk
     blk.mixin mod
     begin
       blk.call
     ensure
       blk.mixout mod
     end
   end
 end

I also agree with Jim’s concern about thread safety.

Robert Klemme: Hey, alright. Thank you for that fix, it is applied.

As for thread-safety, tell me your concerns. Mixin just uses extend and mixout is a single pointer assignment, totally atomic.

While I would love to be able to uninclude modules or otherwise change the inheritance chain, I don’t think this feature is necessary for the examples shown. Here’s a simple way to implement the Builder example (note the local variable "myself")

  def to_html
    myself = self
    Builder.capture do
      html do
        head do
          title myself.friendly_title
        end
        body do
          comment! "HI"
          h1("Header")
          p("paragraph")
        end
      end
    end
  end

And Builder.capture can be almost as simple as

 def Builder.capture &blk
   instance_eval(&blk)
 end

No need to guess who is self, no need to change the inheritance chain, no problems with accidentally overriding methods, …

_why: I think the worries with thread safety are about a thread seeing a class with extended behavior because it interrupted another thread that temporarily extended that class.

Tammer Saleh: Look at mix_eval again. In this case, we’re mixing into objects rather than classes (using extend.) This could still be cause for concern about thread-safety (eventually it might be nice to mixin for only a given scope,) but the concern should be greatly diminished since we’re not effecting the global set of classes, only a single object.

_why: of course, pointer assignment is only atomic on a 32bit machine… =)

This looks like a good deal of fun :-)

Maybe I’ll try my hand at some meta-fu, if you’ll have me for just a moment…

def MethodsOverride(obj_or_methods, &global_method)
  case obj_or_methods.size
  when 1
    meths = obj.instance_methods
  else
    meths = obj_or_methods
  end

  Module.new do
    define_method(:__global_method, &global_method)
    instance_methods.each { |m| undef m unless m =~ /^__/ }

    meths.each do |m|
      define_method(m) do |*args|
        __global_method(*args)
      end
    end
  end
end

Now inject that in your metaclass! :O

Hopefully I’ll have some time later to play with more of an example…

oh drat, well I did forget the odd * and refactor, but you should get the idea, outside the busted arguments!

myself, self = self, myself

lol

Also, atomicity is only the thin end of the pencil when it comes to thread safety. You basically have to completely lock a shared object upon which mixico is in use, because otherwise other threads will be able to see the mixicoed-in methods. Also there are difficulties with frozen objects…

Which is a shame, because the thing that mixico is here being invoked to address really has more to do with method lookup in local execution contexts, something which shouldn’t have any thread issues at all.

@ MenTalGuy: here’s one way to make mixico thread-safe http://coderrr.wordpress.com/2008/11/14/making-mixico-thread-safe/

also it’s possible to make mix_eval a mix_exec (analogous to instance_exec) by calling/yielding to the block with parameters:

class Module
def mix_exec mod, *args, &blk
blk.mixin mod
begin
yield *args
ensure
blk.mixout mod
end
end

end