> >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 don't think it's 'too mushy.'  One could argue that Ruby's flexibility
> in moving between the method and attribute concept is a feature and only
> causes confusion when one is coming from a background where the
> distinction is forced.

Interesting discussion!

Just to illustrate by way of other languages, you can see the contrast in
Java vs. C#.  Java "attributes" are simply methods that follow a naming
convention (getX/setX), while C# has properties which are to a certain
degree woven from a different cloth (e.g. you can reflect on a class and
just examine its properties, as distinct from its methods; and they have a
different syntax when you're writing them).  The times I have seen where it
is truly useful/necessary to distinguish properties from methods are when
you're using code-generation or -automation (serialization and data binding,
for example) or RAD authoring tools.  In the general case I'd prefer to
build methods and attributes from the same parts...