On Tue, Sep 3, 2013 at 12:00 PM, Eric Sorenson <eric.soren...@puppetlabs.com
> wrote:
> [Andy] Here are the possibilities:
>>
> * resource like syntax for classes expresses containment:
>>
>> class container { class { contained: parameter => value } }
>>
>> * a function declares the class *and* expresses containment
>>
>> class container { contain(contained, { parameter => value }) }
>>
>> * a function expresses containment, but does not declare the class
>>
>> class container { class { contained: parameter => value }
>> contain(contained) }
>>
>> * a new "resource type" expresses containment
>>
>> class container { contain { contained: parameter => value } }
>>
>
> I'm most in favour of number 3 here, a function to express the containment
> as a separate thing to declaring the class.
>
+1 to a function expressing containment but not declaring the class (#3).
It's the only option of the 4 provided that doesn't have the side-effect
of adding the class to the catalog. I've run across situations where a
module may want to contain a third party class and relies on some other
module to declare the class. "site" modules are a common example.
A separate, focused, function also keeps our support matrix small and more
maintainable. We'll want to implement the behavior consistently across all
the ways of adding classes to catalogs if we implement the behavior for one
of them. These behaviors are burdensome to maintain over time. A
contains() function allows the behavior to work with all the ways of adding
classes to the catalog while allowing us to maintain the code in one
supported manner.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
