On Sep 3, 2013, at 1:46 PM, Andy Parker <a...@puppetlabs.com> wrote:
> On Tue, Sep 3, 2013 at 12:53 PM, Luke Kanies <l...@puppetlabs.com> wrote:
> On Sep 3, 2013, at 12:06 PM, Andy Parker <a...@puppetlabs.com> wrote:
>
>> On Tue, Sep 3, 2013 at 11:34 AM, Drew Blessing <drew.bless...@buckle.com>
>> 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 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.
