----- Original Message -----
> From: "Andrew Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> Sent: Tuesday, April 17, 2012 9:21:23 PM
> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>
>
> 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.
I think we are kind of generally agreed that nodes are bad, but we have
no idea what might replace them to meet the current needs right now, so
that might be some way off. Certainly its not an incremental improvement
thats easily deprecated - these special vars though would be.
And simply removing them will not solve the basic problem, i think much
of this was covered in the ticket referenced earlier.
>
> > 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.
No cos we can just raise an error if anyone tries to assign, append or
change that hash, its a special, dont mess with it. Effectively a reserved
word. Just like the $settings::foo stuff is today - except they predate
hashes.
These variables represent data that cannot change, its logical that the
variables that hold them are read only. I'd say its what everyone has
expected all along from the variables representing facts but they just
never worked that way.
>
> 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.
Yeah, exactly, I think we do specifically want read only variables
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
