On 2014-07-07 15:43, John Bollinger wrote:
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']?
The evaluation will evaluate both classes before the default expression.
The resources are thus created before the default is added. If we do go
for eager defaults, then the two resources would not get an default values.
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.
If we do defaults per named scope and not do late binding, care has
to be taken to introduce entities in the right order (to get them
evaluated in the wanted order - you want to evaluate nested named
elements after outer elements. This is probably just as confusing to
puppet users as the current way.
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.
Yeah, this is complex, hence this discussion trying to figure out what
to do and how painful certain types of changes would be.
Also see the new thread I started "RFC2 Resource Defaults" that
continues on the Schmitt style for defaults and proposed a cleanup of
the grammar.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lpebdl%24m9i%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
