Hi --

On Mon, 8 May 2006, Logan Capaldo wrote:

>
> On May 7, 2006, at 5:00 AM, dblack / wobblini.net wrote:
>
>> Hi --
>> 
>> On Sun, 7 May 2006, Logan Capaldo wrote:
>> 
>>> I would suggest using the attr_* methods or writing your own accessors for 
>>> any case where you might need to access an instance varible
>>> 
>>> @something = exp
>>> 
>>> is probably a bad sign anywhere but initialize and/or
>>> 
>>> def something=(x)
>>> ...
>>> end
>>> 
>>> likewise a = @something should almost always be a = self.something
>> 
>> It all depends.  The attr_* family uses instance variables to do what
>> it does, but there's no reason that should be viewed as the only or
>> best or likeliest use of instance variables.  It's layered on top of
>> a subsystem (instance variables) that have other uses too.
>> 
>> 
>> David
>> 
> I wans't suggesting only using ivars for accessors, but I believe strongly in 
> the uniform access principle. Even if you using ivars for something 
> completely internal that no one sees, you should still wrap the accesses to 
> them in methods (private ones).

But then you are suggesting that they only be used for accessors :-)

I can't help feeling it's a lot of trouble to do this:

   class C
     def initialize
       self.container = []
     end

     private
     attr_writer :container
   end

rather than:

   class C
     def initialize
       @container = []
     end
   end

if you're just using @container as a state variable here and there.

I think the role of the uniform access principle here is open to
question.  As I understand it, that principle states that the outside
user shouldn't be able to tell whether a value is stored or calculated
-- essentially, an attribute vs. the return value of a method call.
But instance variables are neither attributes nor methods; so they're
not really candidates for being evaluated for uniform/non-uniform
access.  And Ruby's attributes *are* methods.  To that extent, Ruby
actually enforces the UA principle; when you do this:

   obj.something

you know that you've called a method.  There's no other possibility,
so there's no opportunity for divergence of the interface.


David

-- 
David A. Black (dblack / wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
   > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
   > Paper version coming in early May! http://rubyurl.com/DDZ