Fix IRB warnings on Ruby >= 2.2.0

[jessedoyle]

I generally run IRB with all warnings enabled (I have an alias to irb -w setup in my shell).

After requiring the current master branch of Prawn in IRB on Ruby 2.2.0, the following warnings were logged:

> irb -w
2.2.0 :001 > require './lib/prawn'
/Users/jesse/development/ruby/prawn/lib/prawn/text/formatted/line_wrap.rb:153: warning: private attribute?
/Users/jesse/development/ruby/prawn/lib/prawn/text/formatted/line_wrap.rb:154: warning: private attribute?
/Users/jesse/development/ruby/prawn/lib/prawn/text/formatted/arranger.rb:222: warning: private attribute?
/Users/jesse/development/ruby/prawn/lib/prawn/graphics/patterns.rb:79: warning: assigned but unused variable - x1
/Users/jesse/development/ruby/prawn/lib/prawn/graphics/patterns.rb:79: warning: assigned but unused variable - y1
 => true

This patch simply fixes the issues the warnings are generated from.

[packetmonkey]

I'm good with the change to gradient_registry_key however the warning for warning: private attribute? has already been fixed on ruby trunk. I prefer that style and given the warning will go away, I'm inclined to leave it until 2.3 when it disappears completely.

[jessedoyle]

@packetmonkey - I wasn't aware that the warning for private attributes was removed in Ruby trunk.

Regardless, I believe it's going to be some time before 2.2 usage is small enough to be negligible.

Many Prawn users (such as myself) may not be aware of this change in Ruby trunk and see any warnings generated by Prawn as unprofessional. I truly believe the best approach is to write code that doesn't generate warnings on any Ruby interpreter first, then consider personal code style second.

Correct me if I'm misunderstanding, but you prefer:

class Foo

  def some_method(arg)
    self.bar = arg
  end

  private

  attr_accessor :bar
end

over direct modification of instance variables?

Wouldn't instance variables be equivalent to private accessors in this case, but be arguably more simple?

Please don't take this in a negative light, I'm just curious as to your reasoning (or like I said, I may be misunderstanding something) 😃.

[mojavelinux]

I'm inclined to agree that waiting for Ruby 2.3 to fix a warning doesn't seem reasonable. I think we should at least be focused on fixing it for what's already in use (Ruby 2.2)

[crazymykl]

@jessedoyle Yes, but if I then change to using an accessor method with more logic in it, I need to find/replace away the @ all over the file.

[jessedoyle]

@crazymykl - Thanks that makes sense!

It may be useful for a massive and complex codebase, but I don't think it's necessary here.

In this case, classes that were changed were all <= 300 lines of code and the accessors weren't referenced very often. I don't think that this style change is worth the interpreter throwing a warning.

[packetmonkey]

I'll concede it's annoying to throw an unavoidable warning given how we aren't actually injecting any additional functionality here, it's just a style choice with the current code.

I'll merge this in, and once 2.3 is released I'll pick a bigger fight over it :)

Thanks for the feedback everyone!

[jessedoyle]

Thanks a lot Evan!