From: dblack@...
Date: 2003-08-17T10:13:18+09:00
Subject: Re: Newbie Q: Data encapsulation with Ruby

Hi --

On Sun, 17 Aug 2003, Dave Thomas wrote:

>
> On Saturday, August 16, 2003, at 12:31 PM, Meino Christian Cramer wrote:
> >   Until this point I thought, "attributes" _are_ instance variables...
> >   (haveing C++ in mind...)
> >
> Attributes are methods which give you access to instance variables. As
> others have said, they are the quivalent of Java's getters and setters.
>
>     attr_reader :fred
>
> is the same as writing
>
>    def fred
>      @fred
>    end
>
> Ruby is good this way: objects can choose to expose their state
> directly, but then they can change to having more complex method-based
> access. The key thing is that this change is transparent to users of
> the object: when you say
>
>    f.age
>
> you have no idea if you're getting the age as a transparent reference
> to an instance variable or as the result of some computation. Read
> Meyer's Object Oriented Software Construction for a lot of information
> on this - he calls it the Uniform Access Principle, and it's one way of
> increasing encapsulation and decreasing coupling.

I'm finding this thread interesting enough that I shall risk (a)
hair-splittage; and (b) revelation of ignorance, in order to take it
further.

What I'm now getting curious about is the use, utility, and stability
of the whole notion of an 'attribute' in Ruby.  It seems like there's
no such thing as saying, from the outside (i.e., from the perspective
of someone using the class), "This object has a 'blah' attribute" --
which I think is essentially the Uniform Access Principle in action,
but it goes further because even when something is (as close as we get
to) an attribute, it's still just a method that happens to return an
instance variable.  Even from the class writer's perspective, it's not
qualitatively different from writing any other method (the way, say,
using global variables feels qualitatively different from using local
variables).

This is what I was groping at in saying earlier that there's no
separate category of 'attribute' at the language level; it's woven
from the same cloth, so to speak, as all the code around it, but
happens to fulfill a kind of attribute-like function.  Or is that too
mushy a way of looking at it?

I find this all interesting in part because it's something I keep
seeing in Ruby: incredibly simple, consistent, homogenous language
design from which one *can* -- but does not have to -- build and name
constructs which resemble those in other OO languages (all those ones
I don't know :-)  My favorite example is class methods, and the fact
that they are essentially singleton methods added to Class objects by
the same mechanism that singleton methods are added to any other
object -- and that what gives them special-citizen status is that the
concept of a class method exists already and has some proven utility.

It seems to me that if some day everyone decides that 'attribute' is a
superfluous category, or that class methods shouldn't be looked at as
different from other singleton methods -- or if new concepts at that
level of abstraction come into being -- Ruby will be *incredibly*
ready, because these things can just sort of flow out of, and melt
back into, the language....


David

-- 
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav