From: Austin Ziegler <halostatue@...>
Date: 2005-05-07T13:12:10+09:00
Subject: Re: object reference handle (like perl's reference to scalar)

On 5/6/05, Dave Burt <dave@burt.id.au> wrote:
> "Austin Ziegler" <halostatue@gmail.com> contended:
>> Sure, you can create a Ref class. If you look on ruby-talk
>> archives, you'll see several implementations in the past three
>> years. However, such an object is useless. It can't act as the
>> object for which it holds the reference. It won't report as the
>> object for which it holds the reference.
> Why do you assert these things about any concievable Ref
> implementation? Even my Ref implementation does act as the object
> for which it holds the reference for all purposes except
> explicitly querying type and reference reassignment. Surely it's
> entirely conceivable to have a reference object whose only
> difference from the referenced object is that it responds to deref
> and deref=?

I don't recall the problems mentioned, but Ref objects have been
mentioned in the past as problems. If anything does a class-based
check, then the Ref object will never have a chance (and, yes, I do
this in PDF::Writer some; not much, but some). More to the point, I
was looking at the CSV code the other day to help someone and we
saw:

  case foo
  when String
  when IO
  when ...
  end

(1) It doesn't work with StringIO. (2) It can't/won't work with a
Ref object, because you'd need to redefine Class#=== (or is it
Module#===) to get this to work right.

>> (There's one case that I have in PDF::Writer where such a
>> reference would be mildly useful, but the reality of what I need
>> to do here is more the elimination of all instance variable use
>> in what I'm trying to do. And *that* is a different beast
>> entirely.)
> I'd be interested to hear a little more about this, as you've said
> this is a sub-1% problem - it must be interesting.

It's a purity problem. Right now, when you render a SimpleTable, it
makes some modifications to bits of the data in the SimpleTable.
This makes it very fragile. You cannot write the same SimpleTable to
two different PDF files at the same time, because of this. If you
render a SimpleTable, you may get a slightly different result if you
render it again.

I've got a (broken) reimplementation that separate out these
variables into a RenderVars object (it could as well be an
OpenStruct, but this also lets me pull some methods out of
SimpleTable that are really only related to the RenderVars). Doing
this will let me get around the problem of calls like:

  _y, _height = __table_column_headings(_y, @data)

It's that place where a ref-object might be useful -- I update _y in
place rather than by reassignment at the end. But it's a small thing
in comparison to everything else that I do.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca