On Sep 4, 2013, at 5:22 PM, Eric Sorenson <eric.soren...@puppetlabs.com> wrote:
> On Sep 3, 2013, at 12:47 PM, Luke Kanies <l...@puppetlabs.com> wrote: > >> It looks like we shouldn't need to touch the catalog stuff at all to make >> this work, so I agree. Is there a ticket out there for the catalog format >> refactoring? > > We have a Roadmap JIRA issue that I've just cloned into redmine. > http://projects.puppetlabs.com/issues/22408 Ah, thanks. >> >>> [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. >> >> Why? What are the benefits of this, and downsides of the other options? > > Nick Lewis, Erik and I talked through this at more length on IRC, starting > about 15:26 here > http://puppetlogs.com/puppetdev/%23puppet-dev-2013-09-03.log.html > > Seems to have the best intersection of no new syntax/Low surprise to users/no > shift in behavior of existing code. Hmm. Maybe the list of options above is incomplete, but I read the IRC thread differently. I read it as: If class is not included and not contained and doesn't require parameters, contain and include If included and not contained and doesn't require parameters, contain If contained, fail If requires parameters, fail So basically, contain does an include as long as the class doesn't require parameters, but fails if it does. That's exactly what I (and I thought others) recommended, but I thought there was disagreement about. >> >>> [Nick Lewis] A 'contain' function was the decision we came to last time I >>> was involved in a conversation about this. That turned into ticket #13045, >>> which was closed with the decision that it should be fixed in Puppet >>> >>> [Luke] I'm in favor of it as a simple, optional, backward-compatible fix. >>> Basically, if you're using the anchor pattern now, you can use the contain >>> function instead, and properly represents what's going on. >>> >>> +1 >> >> How is it that we're coming to the same decision as we did a year ago, >> everyone seems to agree, most of the players are the same, yet we didn't >> just fix this a year ago? >> >> Or, even, why didn't someone just write the 2 line function and start using >> it? >> > > Is this rhetorical? I honestly can't tell, but I don't think I can answer > these questions. The second question is a bit rhetorical, but it is suprising that someone didn't just create a contain function instead of using the anchor pattern. It's more work to build the anchor type than the function, so I am surprised. In terms of the first, well, I was probably inappropriately exasperated. Sorry about that. -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- 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.
