>> . def a?
>> .    @a ? true : @a
>> . end

> Why not "def a?() @a end"?

Becasue that would be the exact same as 'attr :a'. What would be the
point? This guaruntees only three possible return values: true, false,
and nil.

>> . def b!(x)
>> .    @b.replace x
>> . end

> Hm, I don't like that because it's too special case.

Well, these _are_ special cases. Don't see any reason not to like them
b/c of that. Just dont use them. Since the "functional space" is simply
going unused anyway (i.e. symbols can end in ? and ! without quoting),
and it coorepsonds to certain forms of method definitions, I gave them
the most reasonble base-line usage I could think of.

> Also you might want to be able to assign and to replace...

I think you'd just replace first from the calling routine, and then
assign. Or perhaps I misunderstand?

> Although I find "attr_accessor" quite lengthy, I don't
> really see the benefit of your proposal. And attr_accessor
> does indeed define reader and writer for several attributes

Ah, but there are many advantages, not just the fact that attr is
shorter. You can define both readers and writers in the same call. The
names of the methods defined are returned so you can use public,
private, protected (and user defined methods too!) in front of them.
They also route through a common #define_attribute method, so there is
central control, and it stores all defined attribute methods so you can
ask for a list of them. It also has casting, somthing I came up with a
few years ago. Eg.
..  attr :a => :to_s

which defines

..  def a
..    @a.to_s
..  end

~T.