Easy Proxy

[Robert Klemme]

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.sendalias_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

 

[Glen Holcomb]

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.sendalias_method, meth, :call)
self
end
end

class X
def initialize
@e =3D []
end

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

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

You can even use it for things like this:

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

(-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

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

--=20
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can=92t hear a word you=92re saying."

-Greg Graffin (Bad Religion)

 

[Brian Candler]

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.

 

[Robert Klemme]

-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.


Kind regards

robert