Attr_accessor

wow this attr_accessor thing is really great i can see this saving ALOT
of typing.

Indeed!
This is the kind of stuff that really brings out the “automagic”.
Mr. Hansson really did us all a good thing with knowing Ruby and
knowing ORM and applying these concepts well with a language that
really does lend itself to it. Things are nice now. Sometimes things
are slow, but everyone can be glad things will only get better!

Hi –

On 3/17/07, John J. [email protected] wrote:

Indeed!
This is the kind of stuff that really brings out the “automagic”.
Mr. Hansson really did us all a good thing with knowing Ruby and
knowing ORM and applying these concepts well with a language that
really does lend itself to it. Things are nice now. Sometimes things
are slow, but everyone can be glad things will only get better!

I agree with your assessment of David’s work but he can’t be given
credit for attr_accessor. It’s a core Ruby-language construct.

David

Oh, I don’t mean to give him credit for that, but for recognizing
that type of construct and how it is like the ORM stuff in
ActiveRecord! (unless I’m mistaken) It is a good example of the kinds
of things Rails developers should probably get familiar with
conceptually. (I’m working through your book and the Agile book at
the same time, the different approaches are interesting. Each book
seems to fill in gaps for the other, so I can’t say anyone should
start with one or the other, but both.)

I have no idea what you guys are talking about but whatever it is i’m
sure it makes sense to someone and thats the best gift of all :slight_smile:

Corey K. wrote:

wow this attr_accessor thing is really great i can see this saving ALOT
of typing.

If you want to check that assigned values are valid at the
time of assignment (instead of later during validation),
please consider using “typed_attr” from my “chattr” gem.

gem install chattr

class Foo
typed_attr String :bar do |v| v.size <= 20 end
end

Now you can’t assign a string that’s nil or more than 20 characters
without an exception being thrown.

Clifford H…

Hi –

On 3/17/07, John J. [email protected] wrote:

Oh, I don’t mean to give him credit for that, but for recognizing
that type of construct and how it is like the ORM stuff in
ActiveRecord! (unless I’m mistaken) It is a good example of the kinds
of things Rails developers should probably get familiar with
conceptually.

Yes, definitely. The use of standard Ruby idioms as the basis for
things in AR is central, and a very sound move. When I’m teaching AR,
I usually start with attr_* and all that, on top of which it’s easy to
layer the AR stuff, since it’s largely just a kind of souped-up,
database-aware expansion of the attribute constructs.

(I’m working through your book and the Agile book at
the same time, the different approaches are interesting. Each book
seems to fill in gaps for the other, so I can’t say anyone should
start with one or the other, but both.)

I’ll go along with that :slight_smile:

David

David A. Black wrote:

Wouldn’t it be better to call that checked_attr? I’m just thinking
that it’s mostly checking the class, rather than the type

You have the choice of using class checking or block-based checking,
which can perform whatever type checks are relevant, including
respond_to?
and related checks. The parameter list consists of a list of any of four
kinds of things:

  • a Class (which is used for subsequent class checks),
  • nil (indicating that nil values are allowed),
  • a Symbol, which creates an attribute having the defined checks,
  • any other value, which is used as a default value.
    The block, if any, is applied to all created attributes.

Class checking is just a shorthand limited form of type checking. I’m
fully aware if the distinction, but this method encourages type
checking,
not just class checking, so I think it’s correctly named.

The gem also contains “array_attr”, which creates a subclass of Array
that
overrides every mutating method of Array to provide the same checking
for
array attributes as well (with the exception of nil and default values).

Take a look at the RDoc for more info.

Clifford H…

Hi –

On 3/18/07, Clifford H. [email protected] wrote:

class Foo
typed_attr String :bar do |v| v.size <= 20 end
end

Now you can’t assign a string that’s nil or more than 20 characters
without an exception being thrown.

Wouldn’t it be better to call that checked_attr? I’m just thinking
that it’s mostly checking the class, rather than the type (though
calling size on it implicitly means that it’s of type “object that has
a size method”), so a more generic name might be good.

David

Hi –

On 3/18/07, Clifford H. [email protected] wrote:

  • a Symbol, which creates an attribute having the defined checks,
  • any other value, which is used as a default value.
    The block, if any, is applied to all created attributes.

Class checking is just a shorthand limited form of type checking. I’m
fully aware if the distinction, but this method encourages type checking,
not just class checking, so I think it’s correctly named.

It does indeed sound quite versatile. That, too, puts me in mind of
“checked_attr”, but maybe I’m just basking in your having liked my
‘chattr’ name idea :slight_smile:

The gem also contains “array_attr”, which creates a subclass of Array that
overrides every mutating method of Array to provide the same checking for
array attributes as well (with the exception of nil and default values).

I think there’s a problem with array_attr; I’m getting:

/opt/local/lib/ruby/gems/1.8/gems/chattr-0.9.0/lib/chattr.rb:378:in
`throw’: wrong number of arguments (0 for 1) (ArgumentError)

when I try to violate the constraint on an array. It looks like
there’s a throw just kind of sitting there on its own.

The business of overriding mutating methods of Array reminds me of
some incomplete attempts by me, a few years ago, to add a kind of
native ‘tie’ facility to arrays – meaning, you’d do something like:

a = []
def a.[]=(index, value)
# some thing here that persists the value or whatever
end

and then every change to the array would be laundered through that
operation. In fact, I remember originally thinking that Array would
work that way, and then having it pointed out to me that it doesn’t,
since the mutating operations don’t all converge on []= or anything
else. Maybe I’ll be inspired now to try it again.

David

John J. wrote:

Indeed!
This is the kind of stuff that really brings out the “automagic”.
Mr. Hansson really did us all a good thing with knowing Ruby and
knowing ORM and applying these concepts well with a language that
really does lend itself to it. Things are nice now. Sometimes things
are slow, but everyone can be glad things will only get better!

I am getting the same feelings reading this as experiencing Leo
Buscaglia seminars in the early eighties…

ilan

David A. Black wrote:

I think there’s a problem with array_attr; I’m getting:
/opt/local/lib/ruby/gems/1.8/gems/chattr-0.9.0/lib/chattr.rb:378:in
`throw’: wrong number of arguments (0 for 1) (ArgumentError)
when I try to violate the constraint on an array. It looks like
there’s a throw just kind of sitting there on its own.

My bad. I was using throw when I thought I was using raise.
Subversion has the right code now, and I’ll upload the 0.9.1
gem shortly. Apparently I hadn’t tested that path.

With regard to typed_attr, there are still ways to violate the
constraints: use a default value that isn’t allowed (or not
use one where nil isn’t allowed), or directly assign to the
member variable from a member function. There’s no good way of
avoiding that really though…

Clifford H…