I felt the same way - I have no desire to see Resource and Provider tacked on the end of everything.
From: Jesse Campbell [mailto:firstname.lastname@example.org]
Sent: Wednesday, April 17, 2013 2:27 PM
To: Jay Feldblum
Cc: Chef Dev
Subject: [chef-dev] Re: Re: RE: Re: Re: Re: Re: ::File notation
Why wouldn’t you then call it Chef::ProviderChef::FileProviderChef and Chef::ResourceChef::FileResourceChef?
It just seems a bit redundant… perhaps it would be better if LWRPs did not automatically inherit the Chef::Provider and Chef::Resource namespaces?
On Wed, Apr 17, 2013 at 2:18 PM, Jay Feldblum <email@example.com:firstname.lastname@example.org> wrote:
I suspect that this is an annoyance for programmers who are fluent in Ruby and who want to write providers.
For example, if a provider requires reading a cache file in load_current_resource, the normal expectation is that File.read(cache_file_path) should work. It works in most other Ruby code, and programmers who are fluent in Ruby will have written that same line hundreds of times before. There is a perfectly sensible and easily comprehended reason why it doesn’t this time, and there is a perfectly sensible and easily comprehended workaround with either ::File or IO.
This is not a blocker. But it is a speed bump.
In the name of avoiding all such speed bumps, the resource class could have been named
Chef::Resource::FileResource and the provider class
Chef::Provider::FileProvider. The same pattern could have been extended to all resource and provider classes as well.
On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob <email@example.com:firstname.lastname@example.org> wrote:
Yeah - I’m not clear this is a problem in the vast majority of cases.