From: Doug Glidden <41mortimer@...>
Date: 2008-09-09T01:07:04+09:00
Subject: Re: "Pointer" to an object? (i.e. reflect changes to origina

David A. Black wrote:
[snip]
> You have to know the difference between assignment and object
> mutation, and use whichever you think is right in a given situation.

Okay, but...well, I'll comment more on this in a minute.

[snip]

> The things that come to mind are aliasing methods, overriding methods,
> and possibly writing a modified version of OpenStruct that automates
> the twinning of attributes, or maybe attr_twins or something. It's
> miles from anything that suggests to me a need to re-engineer Ruby's
> object model.

I don't think I'm suggesting re-engineering the object model, merely 
adding the possibility of creating pointers.  It could be (and probably 
is) as simple as adding a Pointer class, but as far as I can tell that 
would require delving into C, which is definitely not my forte.

> It sounds like you're seeing a conflict between wanting a program to
> work a certain way, and writing it to work that way. I don't think
> there's a conflict. If you feel like you're tailoring a library too
> much to a single use case, that's still better than tailoring Ruby to
> a single use case :-) 

I don't think it would be doing that.  I thought Ruby was about 
freedom--it lets you make modifications to pretty much anything you 
want, for goodness' sake--but this seems like a pretty severe 
restriction to me.  I don't see how wanting one object to be able to 
reflect changes to another is such a specialized or rare use case.

> More to the point, if you take a step back and
> write something that handles this kind of use case, you can turn it
> around so that it's beneficial and comfortable and doesn't feel like a
> squeaky wheel.
> 
> 
> David

The long and short is, I don't know how to do this.  Maybe I'm being 
dense, but I'm not catching what you have in mind with the list of 
options above (aliasing methods, overriding methods, etc.).  The most 
elegant solution I've come up with is an ObjectWrapper class...

  class ObjectWrapper
    attr_accessor :wrapped_object

    def initialize(object)
      @wrapped_object = object
    end

    def method_missing(method, *args)
      @wrapped_object.send method, *args
    end

    def respond_to?(method)
      @wrapped_object.respond_to? method
    end
  end

...which still seems decidedly inelegant (not to mention extraordinarily 
wasteful), as it requires wrapping every object that could ever be 
pointed to with it.  IMHO, an object shouldn't need to know that it's 
being pointed to.  In other words, the following is elegant and 
least-surprising, but impossible to implement without dropping into C, 
as far as I can tell:

  object = MyObject.new
  copy = *object
  ...
  object = MyOtherObject.new # object and copy are both changed

On the other hand, forcing the following is neither elegant nor 
least-surprising:

  object = ObjectWrapper.new MyObject.new
  copy = object
  ...
  # I might accidentally use object = MyOtherObject.new -- whoops!  That 
doesn't
  # do what I expected at all, but its not a noticeable error, either.
  object.wrapped_object = MyOtherObject.new # this does what I intended

Furthermore, anywhere in the program that we want to access the MyObject 
instance itself, we have to reference object.wrapped_object, which is 
painful and far too easy to forget.

If Object had a #replace method like String, Hash, Array, et al, that 
would be an acceptable (albeit annoying) workaround, but that's not 
available either.

I'm wide open to better ideas.

Doug
-- 
Posted via http://www.ruby-forum.com/.