Easy Proxy

Ruby
1

Hi,

it just occurred to me that one sometimes might want to use a proxy
for an instance variable which restricts access in some way.

class Proc
def proxy(meth)
class<<self;self;end.send(:alias_method, meth, :call)
self
end
end

class X
def initialize
@e = []
end

def entries
en = lambda {|x| @e << x if x >= 0; en}.proxy(:<<)
end
end

x = X.new
x.entries << 10 << -12 << 23
p x

You can even use it for things like this:

NULL = lambda {|y| y == 0}.proxy :===
POS = lambda {|y| y > 0}.proxy :===
NEG = lambda {|y| y < 0}.proxy :===

(-2…2).each do |i|
case i
when NEG
puts “#{i} NEG”
when NULL
puts “#{i} NULL”
when POS
puts “#{i} POS”
else
puts “#{i} what?”
end
end

Anybody think this should go into the core? (I’m not religious about
the name.)

Kind regards

robert

2

On Tue, Sep 1, 2009 at 7:52 AM, Robert K.
[email protected]wrote:

end

(-2…2).each do |i|
end
http://blog.rubybestpractices.com/

Very slick and in my opinion highly useful. So, I guess I’m saying yes.

–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”

-Greg Graffin (Bad Religion)

3

Robert K. wrote:

Anybody think this should go into the core?

-1, because it’s already easy to add singleton methods and/or build
proper wrapper classes with delegation - and the latter is usually a
better solution longer-term (*)

I do think that << should be more widely implemented: e.g. in Proc as an
alias for #call, and in Hash for ‘add [key,value] pair’, so it becomes
more useful for duck-typing. But I don’t think that’s the point you’re
trying to make here.

Regards,

Brian.

(*) For example, the ‘entries’ proxy you return currently only
implements #<<. What if you later want it to implement #size or #empty?
or #first or …

Also, objects with singleton classes cannot be marshaled.

4

2009/9/1 Brian C. [email protected]:

Robert K. wrote:

Anybody think this should go into the core?

-1, because it’s already easy to add singleton methods and/or build
proper wrapper classes with delegation - and the latter is usually a
better solution longer-term (*)

The question is whether you always need a long term solution. We’re
not all building long term applications with Ruby. And if there is a
feature which makes hacking scripts easier and does not hurt
application development, then why not?

I do think that << should be more widely implemented: e.g. in Proc as an
alias for #call, and in Hash for ‘add [key,value] pair’, so it becomes
more useful for duck-typing. But I don’t think that’s the point you’re
trying to make here.

That’s an interesting point! Then I would also ask for === to be an
alias for Proc#call by default. But wait: and what about +, - etc.?

(*) For example, the ‘entries’ proxy you return currently only
implements #<<. What if you later want it to implement #size or #empty?
or #first or …

Then you just exchange the implementation and use Delagator or
something similar.

Also, objects with singleton classes cannot be marshaled.

True but I don’t see that as an argument against providing such a
method. Otherwise Hash would not be allowed a default_proc either.
:slight_smile:

Kind regards

robert