On Thursday, July 3, 2014 8:29:48 PM UTC-5, henrik lindberg wrote:
>
> On 2014-03-07 22:57, John Bollinger wrote:
> > Here's another idea: how about removing resource defaults altogether?
> > My take on them has always been that their dynamic scope was their most
> > important feature. If that's going away then what's left is just a
> > minor piece of syntactic sugar, and keeping them in that restricted form
> > is certain to cause more pain than than just dropping them would..
> >
>
> There are several kinds of scoping in effect. It used to be dynamic,
> which if I understood this correctly meant that defaults applied from
> where something was defined as well as where it was included.
>
>
Yes, with the clarification that the "where it was included" part was
recursive. I had always thought that created an evaluation-order
dependency for defaults that weren't global. Probably it once did, but the
code described earlier for binding defaults late seems to be an attempt to
address that issue.
> We now flipped that to follow how variables are resolved, if not defined
> in the same scope, it goes to inherited, and then global scope.
Hmm. That's not how I read your description the first time, but I see how
it could be read that way. I don't think it's consistent with eager
application, however, for there is no inherent constraint on classes being
evaluated in an order that makes that work. Consider:
class mymodule {
File { group => 'example' }
}
class mymodule::example {
file { '/tmp/example': owner => 'root', ensure => 'file' }
}
include 'mymodule::example'
include 'mymodule'
File { mode => '0400' }
What should File['/tmp/example']['group'] be? And
File['/tmp/example']['mode']? If part of the objective is to avoid binding
defaults late without (re)opening the door to issues around evaluation
order uncertainty, then you can rely only on the local lexical scope for
defaults. And yes, variable references do suffer from that issue already.
> I agree
> that this pretty much renders defaults useless as they have to be global
> or repeated per class / define. It is only useful if a define or class
> creates many resources.
>
>
> If defaults followed lexical scope / (namespaces). Then the defaults
> would apply to the namespace it is defined in, and all inner namespaces.
> That would make them more useful while also safe to use. They would not
> apply to something that is included.
>
It's not clear to me how that last alternative differs from the previous
one, nor whether it fares any better on the evaluation-order front relative
to my example above. I'm inclined to suspect that any appreciable measure
of "safety" for resource defaults requires either restricting them to their
lexical scope alone or binding them late. I think the idea of changing
their scope must be approached with extreme caution, however, as the
effects of doing so could be subtle and difficult for users to predict, yet
potentially very harmful.
John
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/7d69238f-5bb9-49be-a2bf-d849bec19ad8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
