RCR 277: Make def return something useful

I've got an ugly implementation of this available at

Please not that this way inferior to the Ruby solution because it is not thread-safe. (It works by using the #method_added and #singleton_method hooks and making private(nil) a special case.)

Some additional information about this can also be found on and

- FlorianGross

---

I like decorator, not explicit but easy with other features like this one.

---

I strongly advocate, but think that there's a potential issue with some uses:

  export def self.foo
  end

What exactly should 'export' receive? Simply receiving :foo isn't sufficient; perhaps receiving [:foo, Class.name.intern] or maybe :"self#foo". -Austin

---

I'm still not convinced of the elegance of this; getting a symbol back from a method definition seems to me a somewhat awkward crossing of lines. I don't feel strongly negative about it, though -- but in Austin's example, I would feel fairly strongly that what should be returned should be congruent with whatever is returned without an explicit receiver. Otherwise the reflection required to figure out what's been returned is going to become much gummier than

   def x
   end
   private :x

ever was.

I'm also inclined to think that it should just be :foo, and that doing things with it should be limited to being in the scope of its class, as with private and so forth:

   class << a
     private def x; end
   end

as opposed to defining private so that it's operating from a global perspective and has to parse metadata to determine what to do.

I know what I'm describing is not optimal either, but the [method,class] symbol pair truly strikes me as one of these things about which people will say, "It was pasted on; it's not integral to the language design." I know the underlying problem -- that returning a method object is inefficient -- and I don't have any great solution.

-- David Black

---

I really like the idea of def returning something useful. I cannot say I am especially fond of the idea of returning a symbol. Why not return the new method object? David mentioned that it would be inefficient but why is that the case? If there were Method#name and Method#owning_class methods would it still be inefficient? (conceptually, Methods already know these things because they are returned by Method#inspect)

In the same vein as this RCR, it would also be nice if class returned the class it creates/modifies?

---

def should return the method object. def would then be in turn a method of Class that assigns the method object to the symbol table of the object in question. First-order methods. -rue

---