[chef-dev] RE: Re: Re: RE: Re: Re: Re: Re: ::File notation


Chronological Thread 
  • From: Adam Jacob < >
  • To: Jesse Campbell < >, Jay Feldblum < >
  • Cc: Chef Dev < >
  • Subject: [chef-dev] RE: Re: Re: RE: Re: Re: Re: Re: ::File notation
  • Date: Thu, 18 Apr 2013 19:24:32 +0000
  • Accept-language: en-US

I felt the same way – I have no desire to see Resource and Provider tacked on the end of everything.

 

Adam

 

From: Jesse Campbell [mailto:
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 < " target="_blank"> > wrote:

Adam,

 

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.

 

Cheers,

Jay

 

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob < " target="_blank"> > wrote:

Yeah – I’m not clear this is a problem in the vast majority of cases.

 

Adam

 

 




Archive powered by MHonArc 2.6.16.

§