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.
> That is, can we subtly encourage users to use 'contain' by providing
> compiler hints and such?
>
> […]
>
>
> --
> 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.
>
--
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
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.
