
Not going dark (ruby metaprogramming) - gaika
http://weblog.raganwald.com/2008/06/not-going-dark.html
======
rplevy
I think this would be easier to do if they would improve Ruby's syntax to have
all expressions be enclosed in 2 delimiter characters of some kind (the first
would signify the beginning of an expression and the second would close it).
Expressions can of course be nested. For calling functions, the first element
in the set would be the symbol the function is bound to, and the other
elements would be its arguments. This way functions and data would have the
same notation. These simple changes to Ruby's syntax would make rewriting or
generating expressions, whether at compile time or during run time, much more
graceful.

~~~
etal
Sounds like a brilliant Scheme to me.

~~~
jsmcgd
Liking interesting syntax proposition.

------
tptacek
Rewrite, for people who are more comfortable having their code parsed to an
AST, modified, and recompiled, by a third party library, than they are with
making sure they don't pick stupid method names for Object extensions.

~~~
raganwald
I think some of the suggestions around namespacing methods would also help,
and would help in a very clean fashion. But as long as extending core classes
happens in a single global namespace, there are going to be problems.

Although it wasn't mentioned in this particular post, the problem is acute for
people using extensions for their own third-party libraries. If you install
gem foo, and it uses something with "stupid method names for Object
extensions," your code is now infected with stupid method names for Object
extensions.

What happens if you use gems foo and bar and they conflict with each other?
Even though you went out of your way to eschew Object extensions, the authors
of gems foo and bar may not have been so hygienic.

My hope is that _some_ mechanism for avoiding this problem becomes popular.
This may not be it, but crossing yourself and hoping nobody else uses your
method names or conflicts with each other does not scale very well.

~~~
gregwebs
Part of the problem is Ruby's hackish module system. When you include a
module, you are taking everything, whether you like it or not.

I have created a library to help manage includes, and make them more like
imports in other languages that have real modules. (You can selectively
include methods from a module) <http://github.com/gregwebs/module-import/>

blog post [http://blog.thoughtfolder.com/2008-03-11-real-modules-for-
ru...](http://blog.thoughtfolder.com/2008-03-11-real-modules-for-ruby.html)

If this used some of your ruby parsing magic to analyze dependencies, it would
be a lot better.

~~~
tptacek
I totally don't see how this is a win. The monkeypatch problem is that
multiple people are competing for the same names on Fixnum, String, Array,
Hash, and Object. To solve that problem, your code would need to allow a
Fixnum to support Numeric#to_asn1 in _my_ code, but pretend not to have it
everywhere else.

~~~
gregwebs
This is not a solution to the problem, but it picks away at it. The goal of
this is to prevent unnecessary namespace pollution. So if in your code you say

    
    
      class Object
        import MethodChain, :tap
      end
    

You will never import MethodChain#chain or any other methods into Object, and
you will never have to worry about re-writing those methods.

