Challenging Project ... Need a deep guru to provide enlightenment

ruby-talk
21

Actually, I just went ahead and added a Proxy class to Facets (btw aka
Nano Methods and Mega Modules). Very easy:

require 'facet/blankslate'

class Proxy < BlankSlate

  def initialize( obj )
    @self = obj
  end

  def method_missing( sym, *args, &blk )
    @self.__send__( sym, *args, &blk )
  end

end

What's esspeically nice about this is you can still get to the Proxy
itself.

irb(main):001:0> require 'facet/proxy'
=> true
irb(main):002:0> a = "Hello Dog"
=> "Hello Dog"
irb(main):003:0> ap = Proxy.new( a )
=> #<Proxy:0xb7c21064 @self="Hello Dog">
irb(main):004:0> a.object_id
=> -606004354
irb(main):005:0> ap.object_id
=> -606004354
irb(main):006:0> ap.__meta__.object_id
=> -606009294

Have fun,
T.

22

Biggest place I've hit this is while using DRb and the Qt/Ruby bindings
together. The bindings make extensive use of method_missing calls, and those
just don't work transparently with DRb proxy objects. :slight_smile:

···

On Friday 14 October 2005 05:09, Jeff Wood wrote:

Or to be specifically accurate, DRbObjects aren't transparent enough ...
they don't provide you with the list of available functionality
appropriately.

23

On the way to work this morning, I even got it executing remote blocks ...

so client code looks like:

require 'roxy'
obj = Roxy.new( "otherhost", 4242 )
obj.func( [ 1, 2, 3 ] ) { |a| puts a }

... I just have to figure out how I'm going to deal with syntax that is
multi-layered...

blah.call.call2.call3

with how I have things now, blah.call would be run proxied, but .call2.call3
would be run locally on the result of the first call.

Anyways, that's about the only issue I have left to work out... I'll post
soon, better to post early than not at all :wink:

j.

···

On 10/14/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

On Fri, 14 Oct 2005, Jeff Wood wrote:

> Actually I wrote a new chunk of code based on Ara's snippet that for
direct
> calls does EXACTLY what I want it to ... I'll be posting it later today
...
> I just have to deal with stuff like blah.call.call2.call3 ... which I
don't
> believe will currently work ... I'll have to dig through and see how DRb
> makes it work ... DRbObjects don't work ... call methods or call
> respond_to? ... they are NOT calls on the remote object ... I don't
believe
> ANY call on a proxied object should be local, they should ALL be passed
over
> the wire ( and yes, I know that at least id and send can't, but
everything
> other than those ). I really think you guys will like the stuff I have
...
> So far, I'm calling it Roxy ...
> Thanks.
> j.

sounds neat - now that i understand what you're after. i guess that
approach
would be find so long as one has __some__ method to determine what the
heck
the object 'really' like:

proxy.__drb #=> the obj
proxy.__drb? #=> true

but i like the sound of making drb objects as close to local ones at
possible.

look forward to seeing what you come up with.

-a
--

===============================================================================
> email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> phone :: 303.497.6469
> Your life dwells amoung the causes of death
> Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood

24

something recursive like

   obj.class.instance_methods.each do |m|
     module_eval <<-code
       def #{ m } *a, &b
         Roxy::new( send "#{ m }", *a, &b )
       end
     code
   end

so, every return value of Roxy must, itself, be a Roxy.

this sounds very nice.

-a

···

On Sat, 15 Oct 2005, Jeff Wood wrote:

On the way to work this morning, I even got it executing remote blocks ...

so client code looks like:

require 'roxy'
obj = Roxy.new( "otherhost", 4242 )
obj.func( [ 1, 2, 3 ] ) { |a| puts a }

... I just have to figure out how I'm going to deal with syntax that is
multi-layered...

blah.call.call2.call3

with how I have things now, blah.call would be run proxied, but .call2.call3
would be run locally on the result of the first call.

Anyways, that's about the only issue I have left to work out... I'll post
soon, better to post early than not at all :wink:

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

25

Yeah, but I have to tell the server side WHICH object to call the methods on
... that's what's gumming me up.

I'm glad I've peaked your tastebuds ... It's very close ...

I'll either start it as it's own project or stuff it into nano or mega.

j.

···

On 10/14/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

On Sat, 15 Oct 2005, Jeff Wood wrote:

> On the way to work this morning, I even got it executing remote blocks
...
>
> so client code looks like:
>
> require 'roxy'
> obj = Roxy.new( "otherhost", 4242 )
> obj.func( [ 1, 2, 3 ] ) { |a| puts a }
>
> ... I just have to figure out how I'm going to deal with syntax that is
> multi-layered...
>
> blah.call.call2.call3
>
> with how I have things now, blah.call would be run proxied, but
.call2.call3
> would be run locally on the result of the first call.
>
> Anyways, that's about the only issue I have left to work out... I'll
post
> soon, better to post early than not at all :wink:

something recursive like

obj.class.instance_methods.each do |m|
module_eval <<-code
def #{ m } *a, &b
Roxy::new( send "#{ m }", *a, &b )
end
code
end

so, every return value of Roxy must, itself, be a Roxy.

this sounds very nice.

-a
--

===============================================================================
> email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> phone :: 303.497.6469
> anything that contradicts experience and logic should be abandoned.
> -- h.h. the 14th dalai lama

===============================================================================

--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood

26

It's own project would be best, IMHO. There's nothing wrong with small
projects, especially when they stand alone as well as this does.

Thanks,

Kirk Haines

···

On Friday 14 October 2005 10:01 am, Jeff Wood wrote:

Yeah, but I have to tell the server side WHICH object to call the methods
on ... that's what's gumming me up.

I'm glad I've peaked your tastebuds ... It's very close ...

I'll either start it as it's own project or stuff it into nano or mega.

27

I just posted an announcement outside this thread for version 0.1 of
the project.

Just waiting for rubyforge to approve the project, then I can post source.

j.

···

On 10/14/05, Kirk Haines <khaines@enigo.com> wrote:

On Friday 14 October 2005 10:01 am, Jeff Wood wrote:
> Yeah, but I have to tell the server side WHICH object to call the methods
> on ... that's what's gumming me up.
>
> I'm glad I've peaked your tastebuds ... It's very close ...
>
> I'll either start it as it's own project or stuff it into nano or mega.

It's own project would be best, IMHO. There's nothing wrong with small
projects, especially when they stand alone as well as this does.

Thanks,

Kirk Haines

--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood