On Apr 17, 2012, at 10:08 AM, R.I.Pienaar wrote:
>
> We then started going down the route of saying all this leaky scope stuff
> is bad, its magical, its non deterministic, when you read a piece of code
> you have no idea what data you are actually looking at. Is it a fact, or
> a variable, a node variable a variable in the define scope or in the class
> or something else entirely.
>
> The fact that facts can be overridden is complete insanity.
Sure, I think I agree for the most part.
>
> We started fixing this by deprecating the dynamic lookup stuff and leaky
> scope things and introducing parameterized classes and started logging
> warnings and deprecations whenever any of this magical variable overriding
> is happening.
>
> So now we're rapidly approaching a world where these leaky scope problems
> are a thing of the past, instead we have clear obvious variable origin, you
> can more or less imagine looking at some modern puppet code and *know* where
> a variable might come from.
>
> EXCEPT in the case of top scope and node scope variables. They're the glaring
> omission in our plan thus far.
>
True. So what I suggested was either give nodes a special status to change the
top-scope, which seems to be universally acknowledged as a bad idea.
So another choice is to just remove nodes, which removes this problem entirely,
doesn't need any new syntax, nor does it need any special variables.
> We have facts that are facts, facts should be constants they should be
> immutable
> instead they're kind of magical and depending if your remember to do
> ::operatingsystem
> you might not get what you thought you would get. The proposed fix to node
> variables is a step backward into this confusing state.
>
Other than because of bugs, facts are immutable, they are just shadowable. We
can end up with the illusion of mutation of variables because of the strange
interactions of inheritance with variable lookup and sequence of evaluation. In
order to get rid of some of this confusion, I suggested an alternative, which
is to remove node from the language.
> Instead we're suggesting we use the hash capabilities - a recent addition -
> to create clear named scopes and types of variables
>
> The hash $facts would be all the facts, they would be immutable and unchanging
> The hash $node_facts would be all node scope variables
> The hash $master_settings would be puppet master config settings replacing
> $settings::foo
>
> and so forth and so on - I dont care for what these are called - but the point
> is once you've taken a newbie and explained to him what a fact is wrt to
> puppet
> and when he then come across a piece of code that says:
>
> notify{$facts["operatingsystem"]: }
>
> there's no room for confusion, its clear as day what we're talking about and
> we can clearly enforce the immutability of these variables etc.
>
If you don't like the idea of facts being shadowed or appearing to mutate, then
this won't get you there. If facts are in a hash, then you can still shadow
that name in another scope. You can also use the append operator (+=) to create
a modified shadowed copy as well.
If you want to keep them in this hash syntax, then we'd have to make $facts in
some way special so that it doesn't allow many, normal variable operations to
be done with it. That seems to take us back into the realm deemed magic.
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
