Long term, I hope Ruby finds some ways to increase performance for lower level programming. I’d like to use Ruby for everything. It is getting faster, but still not ideal for some types of algorithms. I would also love to see compile time (or load time when interpreted) eval expressions as another option when implementing DSLs. That could improve performance significantly for many DSLs.

My pipe dream is to see Ruby become more of a multi-paradigm language. Smalltalk style programming should always be the core, but adding let expressions (and guards) would be cool. I could envision them defined in classes, modules, and methods. Those expressions could have a Haskell-style static type system. Static typing at the expression level would not interfere with standard duck typing. A Haskell-style type system for expressions could improve performance and abstraction at the expression level. For performance reasons, there would probably need to be limitations on re-definition. I think it would be the best of both worlds. Kind of like OCaml in reverse.

class FooController < ApplicationController

before_filter do
singleton_class.class_eval %{
refine Foo do

def bar
"beer"
end

end
}
end

def index
render text: Foo.new.bar # returns "baz", but should return "beer"
end

end

“A toolkit of support libraries and Ruby core extensions extracted from the Rails framework.”

Having to “use” a bunch of AS modules in everything would be really annoying, and introduce a lot of duplication in code (and maybe slow things down). Liking or disliking that idea is outside of the scope of this (probably).

But for the proposed changes to ruby core by adding “refinements”, I like that idea. I find the syntax strange, since what you are doing isn’t really “refining” a class, it’s like extending it in most cases. I really don’t care too much about what it’s called, just a thought. I like the #used callback and the #using syntax since it will clearly show that a module is being added that changes other classes.

If Right::AWS depended on camelize for its own usage it should either depend on activesupport or implement it itself in a util module. (as it was looking for activesupport) I personally think activesupport should not have a monopoly on opening classes for itself either. When I use activesupport I am very careful to require only what I need because I do not like how it opens a lot of classes.

Actually no, it applies to all methods of the class or its subclasses that are defined after the “using” is evaluated, which may be at least partly a bug.

I suspect that when the dust settles, it will end up working like you described. Anything else is too chaotic.

http://groups.google.com/group/ruby-core-google/msg/7ccc375905dda23c

In short, I think they need to be trully lexically scoped, or there will be intractable performance and/or concurrency issues that result. It should not be possible for a given scope to become “refined” long after it has been parsed, as in the instance_eval cases.

It seems like this will solve one of the uglier things in Rails – the leakage of internal AssociationProxy methods that makes them visible outside the proxy. charity.campaign.target should be the target attribute of the campaign, not the associated model of the campaign association proxy.

On the other hand, Right::AWS is not a library that provides core extensions, nor does it depend on such a library (if it did, it would end up in the same place as DataMapper and ActiveMerchant, which is an unsatisfying but somewhat more grey area). Since it only creates the helpers for its own use, it should use utility methods to avoid the problem described in this post.

“In general, Right::AWS should have done something like Right::Utils.camelize in their code to avoid this problem.”

Why was the onus on Right::AWS to use Right::Utils.camelize and not on ActiveSupport to do something similar?