On Tue, Jan 12, 2010 at 9:11 PM, Jeff [email protected] wrote:
On Jan 12, 9:48 am, Gregory B. [email protected] wrote:
Gregory, that’s interesting. Maybe any Ruby library that reaches
sufficent mass use will run into this problem.
But I think the underscore doesn’t really solve the problem, right?
Let’s say you use @_file in your module that I include. You probably
use #nodoc# around it so I don’t even see it in the rdocs. So then my
class I’m about to do @file, but I think, someone might derive from my
class, so I’d better call it @_file. Collision again.
In either case, it’s your fault if you don’t read upstream source.
But if you’re trying to make life easier downstream, it’s less likely
to clash with @_file than it is with @file by accident.
But I agree, @_whatever is ugly and I’m not sure I will introduce it
into Prawn. I just understand why the Rails guys did it after having
a bit of direct experience.
So I say, let’s not use the hard-to-read underscores, and document
ivars in the rdocs like everything else.
I don’t think that internal state benefits from public documentation,
as that just invites one more thing that can get out of date fast, and
invites more danger than it’s worth.
I think one real solution is to avoid ivar references in modules
(using method calls), and prefer composition over sub-classing. But
this is edging on the sort of discipline you’d find in functional
languages, which tends to feel a bit too stuffy for some folks.
I’m about to do some major refactoring in Prawn in the near future. I
might play with these thoughts and see where they lead. If I shake
anything loose that’s worth sharing, I’ll write it up on the RBP blog.