On Tue, Oct 12, 2010 at 1:00 PM, Markus Roberts <[email protected]>wrote:
> > > > + if resource.resource_type.is_a? Puppet::Resource::Type >>> + resource.resource_type.instantiate_resource(scope, resource) >>> + else >>> + scope.compiler.add_resource(scope, resource) >>> + end >>> >> >> I don't like this one. Can we use duck typing here instead of testing for >> ancestors? >> > > Agreed. Also, since scope.compiler.add_resource(scope, resource) is being > called somewhere in the middle of instantiate_resource, it looks like this > decision is being made at the wrong level. > > If the call to add_resource *must* be in the middle it should probably be > moved to the base instantiate_resource method and called as super in the > Puppet::Resource::Type version; if it's not obligatory it should be pulled > out, making the base version of instantiate_method null. If neither of > these is acceptable it's probably indicative that it's all in the wrong > place. > > I detect a code smell here too. But IMHO the problem goes much deeper than this particular patch. The root problem is that if the resource getting instantiated is a user-defined type (hostclass or definition), resource.resource_type is an instance of Puppet::Resource::Type, but if the resource getting instantiated is a built-in type, then resource.resource_type is actually a Ruby class representing the built-in type. The two different possible types of resource.resource_type aren't just unrelated in the class hierarchy, they're even at different levels of abstraction. If the type hierarchy were more sane, and there were a base class which both user-defined and built-in derived from, I would be all for following these suggestions. But those two improvements would both be outside the scope of this patch. Given the situation we are in, where we essentially need the code to have two separate behaviors depending on what the type of resource.resource_type is, it seems to me the clearest way to do that is with is_a?. -- 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.
