From: Tom Sawyer <transami@...>
Date: 2002-06-27T16:55:32+09:00
Subject: Re: []<<

> No. You would then need [](insert any mutator method of the returned
> object here) methods, which would drive you bonkers in the end, since
> you can't possibly be sure about them all...

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?

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?

prob w/ freezing is as you said, it freezes up the instance on the
inside too.

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.

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

a real solution calls for a means to truly designate an object
read-only. does such a means exist? if not, would it be worth enhancing
ruby to support it?

~transami


On Wed, 2002-06-26 at 06:13, Kent Dahl wrote:
> Tom Sawyer wrote:
> > tt['test'] << '..2'         # how come you can do me?
> 
> Keep in mind that the first part just returns an object. Once you have a
> reference to an object, you can call any method you like on it, that
> isn't private or protected. This includes <<.
>  
> > it seems to me that the main point of accessors and the []= method is to
> > control accessiblity to a class' instance variables. right? but as this
> > example shows, there are ways in which "back-doors" exist.
> 
> If you let your objects out to the surrounding world unprotected (or
> unfrozen) these things will happen. Take a look at the dup suggestion
> from Jim, or consider freezing your objects before returning them. (This
> will mean that you have to create a new object if you want to change it
> on the inside, and deny any access on the outside. Sounds like a matter
> of preference and optimization consideration.)
> 
> Or you could be nasty and do like this before you return:
> $ irb
> irb(main):001:0> a = [1,2,3]
> [1, 2, 3]
> irb(main):002:0> class <<a; private :<<; end
> Array
> irb(main):003:0> a << 5
> NameError: private method `<<' called for [1, 2, 3]:Array
>         from (irb):3
> 
> 
> > shouldn't there be better control of such thing? i came across this when
> > i was actually trying to create a []<< method, and realized that i have
> > never seen such a beast before! shouldn't such a thing exist?
> 
> No. You would then need [](insert any mutator method of the returned
> object here) methods, which would drive you bonkers in the end, since
> you can't possibly be sure about them all. Freezing or dup-ing sounds
> alot more sensible.
> 
> -- 
> (\[ 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___)
>