On 2014-15-03 16:54, Daniele Sluijters wrote:
Hi,
I like just about everything in the proposal but I have my doubts about
this:
> The class scope looks up unqualified variables in the class itself, if
> not found there, it continues up the parent chain of scopes. If the
> class inherits from another, then, the parent scope is one that
> represents its super class.
'Dynamic' scoping has always tripped up people in Puppet and caused
interesting side-effects. Even though your implementation's behaviour is
well defined I think it'll only add to the confusion because the
implementation is different from what currently exists. I'm afraid that
people will expect lookups to work one way but depending on the Puppet
version that behaviour changes introducing the possibility for all kinds
of subtle bugs. This might get very troublesome for community module
maintainers too.
The proposal is not really "dynamic scoping", but yes it is different
than 3x - so maybe best to make rules even simpler (as you propose below).
Personally I'm of the inclination that if a variable is not defined
within the current scope you need to be explicit about where you want to
get it from and just bring it in through the fully qualified name. If
that sometimes means you need to explicitly pass a variable down the
chain all the better because it immediately becomes obvious where it's
coming from.
That makes it totally clear where things come from. The only thing that
would need to be different (from what is proposed) is if we want to add
protected attributes to classes (only visible to itself and subclasses).
That would complicate the index in the global scope somewhat, but can
probably be implemented to not have a performance impact (i.e. extra
index, only checked last if caller should have access).
Sure experienced programmers or people who are more familiar with how
the scoping model in Puppet works will be able to use this to their
advantage but the code that's produced and potentially released might
not be easy to understand for others.
Yeah, and how it works today is a mystery to most Puppet Users, even
experts are tripped up by some of the quirks.
It will interesting to see how the different ideas works in practice. We
have a goal to "not break every module" in the initial release of 4x,
and having the new simpler/stricter lookup rules may be too much
breakage to tolerate and we have to introduce a "legacy name resolution"
option or something like that to help migration. Whatever we do we need
to make sure that a well formed 4x (not using any other new 4x features)
also work on 3x.
- henrik
On Saturday, 15 March 2014 04:48:31 UTC+1, henrik lindberg wrote:
I have a long and rambling response written in several installments
between meetings - so I apologize if it is not completely consistent...
To summarize the proposal for 4x (starting out with the cleanest most
strict to see what this means in practice):
1. unqualified variable references is "what can be seen in this
evaluation scope, outer evaluation scopes, and then global"
2. qualified variable references are absolute
3. definition of classes and defines with relative names are named
relative to the namespace it is in
4. resolution of qualified names used as references (for include etc)
are absolute
The rationale for 2, 3, 4 is that this is faster, most user seem to not
trust relative name resolution and throw in :: everywhere (for both
sanity and speed). For those that actually understand how it currently
works and actually wants relative name resolution it does mean a bit
more characters to type with a small loss in ease of refactoring
(moving
a class means it can resolve against other classes than before - both a
blessing and a curse).
We are contemplating having an alias feature.
I then ramble on about scope and try to answer questions...
Regards
- henrik
--
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/lg2rm5%24hbb%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
