make sub classing flay work #67
Conversation
| @@ -63,7 +63,7 @@ def self.parse_options args = ARGV | |||
|
|
|||
| OptionParser.new do |opts| | |||
| opts.banner = "flay [options] files_or_dirs" | |||
| opts.version = Flay::VERSION | |||
| opts.version = VERSION | |||
There was a problem hiding this comment.
Not sure I agree with that one... I guess it depends on what you're trying to achieve w/ the subclass?
There was a problem hiding this comment.
If I build a FooFlay and it has a FooFlay::VERSION, then using fooflay -v should show fooflays version
There was a problem hiding this comment.
Yeah. I get that... theoretically... but is Flay::VERSION no longer relevant? You are subclassing it so I figure you want to report it somewhere.
What does your subclass do?
There was a problem hiding this comment.
the subclass overwrites the default options and some methods ... does not need the VERSION, but it is theoretically wrong to hardcode the class so I'm removing all the hardcoded classes so nobody has to come back here and to make it consistent
| @@ -170,7 +170,7 @@ def self.load_plugins | |||
| # Create a new instance of Flay with +option+s. | |||
|
|
|||
| def initialize option = nil | |||
| @option = option || Flay.default_options | |||
| @option = option || self.class.default_options | |||
There was a problem hiding this comment.
if Fooflay overrides Flay and defines overrides default_options, then these options should be used and not the original Flay options ... atm it makes overriding do nothing
|
Good to go ? ... or is there any advantage to having these hardcoded class names ? |
I'm trying to subclass Flay, but it always calls the base class which breaks because it does not use overwritten methods. This also simplifies the code in the static methods.
@zenspider