Re: []<<

Tom Sawyer wrote:
> then i have to ask: why do we have []=? taking a consistant analogous
> approach would suggest that all we should have is an = method, but we
> don't have that either! this is interesting as it means = is purely a
> statement and exists outside the scope of object-orientation. having
> heard so often that Ruby is 100% oo, my first guess would have been that
> the Object class would have some sort = method. but perhaps that's an
> impossibility?

This is because variables aren't objects and thus a plain = is a
statement.

The reason we have []= is because of the same reason we have
obj.attribute=(val) as an attribute writer to mirror the obj.attribute()
attribute reader. Similar level of indirection (esp. when you start
looking at Hash)
 
> so anyhow, having heard a few solutions, i guess all i'm really getting
> at is that i was very suprised that the "shortcut" module method
> attr_reader dosen't already do something like that. for when i say
> attr_reader :myvar, that's exactly what i mean, R..E..A..D..E..R... know
> what i'm saying?

Yeah, but then again, this wouldn't be extremely useful. For numbers, it
already works like you intend, since they are immutable.
 
> prob w/ freezing is as you said, it freezes up the instance on the
> inside too.

That should be no problem, since on the inside, you can assign to the
variable, no? It makes changes possibly more slow and memory consuming
(need to make new instance with changes, cant use chomp! etc), but
shouldn't really be much.
 
> prob w/ dup is the loss of connection to the orig --later changes from
> within the class won't be reflected and changes on the outside will
> seemingly work enven though there is no actual reflection within.

Hmm. The first would be a problem with freeze too, even if you do
reassignment internally.

> you approach with an object class works best but again you have to
> identify each and ever possible write method --no better off then []<<.

Sounds like you want an intelligent proxy. Return a delegator that stops
all access that might change it. 

A naive approach: Use method_missing in a wrapper object, and filter on
= and ! signs in the methods called.

Another naive approach: use a wrapper object that both holds reference
to the internal, dynamic data, and a frozen, dup'ed version that you
forward to when used. If you want it to be synced to the internal,
dynamic data all the time, I guess you'd have to dup and freeze it every
time it is accessed thru the wrapper.

But I must say, it sounds like there is a Observer pattern trying to get
out from inside the problems you present.

-- 
(\[ Kent Dahl ]/)_    _~_    __[ http://www.stud.ntnu.no/~kentda/ ]___/~
 ))\_student_/((  \__d L b__/  NTNU - graduate engineering - 4. year  )
( \__\_/__/ ) _)Industrial economics and technological management(
 \____/_\____/ (____engineering.discipline_=_Computer::Technology___)