Yes, you're right, Stefan. It would be nice to find a way to reduce the number of implementations of insync?. Deriving classes from Puppet::Property::List and Puppet::Property::OrderedList would take care of some of the implementations. Another option would be to allow types to provide a "canonicalize" method which converts a supplied value into a canonical form (e.g. by sorting it, converting it to a string, or whatever else is appropriate). Then there could be a single insync? method that canonicalizes the "should" and "is" values before comparing them.
I'll file a ticket to this effect. On Wed, Jan 26, 2011 at 12:29 PM, Stefan Schulte < [email protected]> wrote: > On Tue, Jan 25, 2011 at 03:16:48PM -0800, Paul Berry wrote: > > Created a method safe_insync? which first checks whether the property > > has a "should" value of nil, and if so returns true. Most insync? > > methods were already doing this, but a few were not, leading to bugs > > if a property was being audited but not set. > > > > Types should continue to override the insync? method, but callers of > > insync? should call safe_insync? instead. > > Hm this will be just another layer I have to understand what is going on > and what checks are performed in what stage. In my opinion the best »fix« > would be to not overwrite insync in the first place. A few types for > example are overwriting it because they want to compare the full should > array and doing something like > > is == @should # or is.sort == @should.sort > > if they wouldnt use Puppet::Property but Puppet::Property::List/OrderedList > instead, they wouldnt have to do this. > > -Stefan > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
