----- Original Message -----
> From: "Andrew Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> Sent: Tuesday, April 17, 2012 5:05:21 PM
> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
> 
> 
> On Apr 17, 2012, at 2:03 AM, R.I.Pienaar wrote:
> 
> > I like the general idea for sure, but I think it still leaves way
> > too much
> > magic and layering and things that kind of needs to be studied to
> > be understoof
> > rather than just be obvious.
> > 
> > So I'd like to just mention that a few of us thinks rather than fix
> > the
> > mistakes of the past by incremental tweaking we should be
> > rethinking it
> > completely:
> > 
> > http://projects.puppetlabs.com/issues/11915
> 
> I'm not sure that this is a direct overlap with that issue. The
> problem there is essentially how to stop polluting a global
> namespace and make origin of data a bit clearer so that a small
> snippet should be enough to inform the reader.
> 
> What I am trying to address is issue of what it means for a node to
> shadow a top-scope variable. Another possible solution is that we
> just remove node from the language. Then the entire issue goes away,
> but everything is still possible and probably a lot clearer.

Yes, I get that.  But rethinking how we do variables all together would
avoid the problem you're trying to fix.

I think having a node variable merge in with top scope variables might
be acceptable in most cases - its roughly how things used to be have - but
its magical and weird and just not clear whats going on.

Having that magical behavior supports how people tend to use puppet but it
also tends to support the common pitfalls people have with puppet as it 
encourages a bad design of code.

We should either say we have a data story that revolves around:

- facts
- parameterized classes
- ENCs and systems like Hiera

these are all hard non magical things, you know where your variables come
from. You know what they are and what can override them.  Mix in the @facts
style syntax and this story becomes even clearer.

If we were to expand this list to include:

 - magical node variables that can override top scope vars in some cases


Then it's quite clear to me which is the elephant in the room and shouldnt
be there.

-- 
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.

Reply via email to