RCR 331: Remove 'true' parameter from #attr

Abstract

RCRchive		Top	Help	Register	Sign in	RSS	Contact	Credits

I'd like to see the "true" parameter removed from #attr. Either leave it without the ability to create a writer altogether, in which case attr_accessor woud have to be used in it's stay, or allow the attribute/method name to be appended with '=' for that use case. Eg.

  # create reader
  attr :foo
  # create reader and writer
  attr :foo=

Problem

I propose this for two reasons.

First, using a "boolean" parameter like this is not very programmer-friendly b/c it gives no indication of what the parameter does; so it's not nice Literate Programming. This topic has been discussed before on Ruby-talk.

Second and more importantly, the parameter makes it inconvenient to expand on attr's functionality without causing potential compatability issues with other's prior code.

In our specific case in Nitro, we would like to extend #attr to be able to take annotations. Right now we can do this for example:

  attr :x
  ann :x, :default => 10

But we'd like to do:

  attr :x, :default => 10

The boolean parameter on #attr is the only thing preventing a _clean_ extension.

Proposal

Either just remove the 'true' parameter from #attr, or do so and replace it by allowing 'attr :foo=' syntax. This later actually makes a lot of sense since that is exact name of the method it will create anyway.

I've looked at Ruby source and there are only a few places that use the 'true' parameter.

  ext/tk/sample/tcltklib/sample2.rb:      attr :com_disk, TRUE
  ext/tk/sample/tcltklib/sample2.rb:         attr :oval, TRUE
  lib/shell.rb:    attr :cascade, true
  lib/shell.rb:    attr :debug, true
  lib/shell.rb:    attr :verbose, true
  lib/shell.rb:  attr :umask, true
  lib/shell.rb:  attr :record_separator, true
  lib/shell.rb:  attr :verbose, true
  lib/shell.rb:  attr :debug, true
  lib/sync.rb:  attr :sync_mode, true
  lib/sync.rb:  attr :sync_waiting, true
  lib/sync.rb:  attr :sync_upgrade_waiting, true
  lib/sync.rb:  attr :sync_sh_locker, true
  lib/sync.rb:  attr :sync_ex_locker, true
  lib/sync.rb:  attr :sync_ex_count, true
  lib/tracer.rb:    attr :verbose, true
  lib/tracer.rb:    attr :stdout, true
  lib/irb/ruby-token.rb:    attr :name, true
  lib/rdoc/parsers/parse_rb.rb:  attr :skip_space, true
  lib/rdoc/parsers/parse_rb.rb:  attr :read_auto_clean_up, true
  lib/rdoc/parsers/parse_rb.rb:  attr :exception_on_syntax_error, true
  sample/drb/dchats.rb:  attr :name, true

Analysis

Since this interface for #attr is defined in core, only deprecation of its use by Ruby proper can alleviate the problem. And given the nature of the problem, I don't see an other solution but the one(s) presented.

Understandably there is the issue of backwards compatability. But thankfully the feature isn't used extensively; usually attr_accessor is used instead, and updating ones code to take it into account is very simple and straightfoward.

Implementation

Fairly self-explanitory.

Comments

Current voting

I would like to see *all* Boolean parameters replaced with expressive methods names (instance_methods(false) being another one that comes to mind. I'm less sold on the attr :foo= thing... it kind of violates the tidiness of just saying :foo and having the automatic syntactic sugar assignment thing. Then again, it only violates it in a way that's invisible when it's actually used.

I would actually think it would make sense for attr to do what attr_accessor does currently. _reader and _writer could then be the specializations.

David Black

I agree with David. It doesn't make sense that attr_writer, attr_reader, and attr_accessor accept multiple attribute names, and attr only accepts one. I think the most common case is attr_accessor, so attr should match that:

 class Foo
   attr :bar, :baz, :bur
 end

Strongly opposed	0
Opposed	1
Neutral	0
In favor	2
Strongly advocate	2

If you have registered at RCRchive, you may now sign in below. If you have not registered, you may sign up for a username and password. Registering enables you to submit new RCRs, and vote and leave comments on existing RCRs.
Your username:
Your password: