On Sep 3, 2013, at 1:46 PM, Andy Parker <[email protected]> wrote: > On Tue, Sep 3, 2013 at 12:53 PM, Luke Kanies <[email protected]> wrote: > On Sep 3, 2013, at 12:06 PM, Andy Parker <[email protected]> wrote: > >> On Tue, Sep 3, 2013 at 11:34 AM, Drew Blessing <[email protected]> >> wrote: >> I've been following this discussion for some time. As it progressive I've >> found myself fighting internally, going one way and then the other about how >> this should really be. I keep coming back to the same place - this is a >> bug and Luke's original statement is very important: >> >> The fix should require no changes to syntax or usage; merely the cessation >> of use of the anchor pattern. >> >> >> I don't think adding a new 'contain' function is really appropriate. From a >> module developer standpoint what does 'contain' mean? Why should I use it? >> When should I use it? I think it will cause so many questions that you'll >> end up with a whole different problem on your hands. On top of that you >> will have people that just continue to use 'include' and the problem will >> still be there. >> >> >> This is the tradeoff between changing existing language constructs to match >> some user's expectations, and thereby breaking some manifests, or adding >> something new to express the specific concept of containment, and thereby >> requiring users to make a conscious choice about what they want. I agree >> that pawning this off on a user is not ideal, which is why I've argued for >> changing the semantics of the resource like syntax for classes. However, as >> jcbollinger has rightly pointed out, that change would break a lot of >> things, and would also be a major shift in the way many users understand the >> language. >> >> This is the reality we find ourselves in. Over the course of the discussion, >> I think jcbollinger's proposal is probably the best for existing users. >> Those who are currently using anchors would be able to change to the new >> contain() function. Existing manifests would not need to change, but they >> could be updated to use the new function. Luke also brought up another >> alternative for creating a new container kind (module {} or something like >> that). I think that would be another good avenue to explore. > > How difficult would it be to build tools to help our users understand when > they might be making a mistake in this area? > > > Warning is easy. Warning correctly is hard. We would need to come up with > heuristics that would identify code that is absolutely correct, but may not > mean what the user wants. So are there patterns of usage where we can with > 95% (or more) certainty say that it represent a mis-contained class? However, > we would also want some way of suppressing those warnings for the cases where > we get it wrong.
Yeah. I could see this also added to a strict mode or something. Ideally we'd have that top-level container that defaulted to 'contain', and then we could warn any time a top-level class wasn't one of those, but we don't have that, so... -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
