Issue #5046 has been updated by Dan Bode.

I agree with this, although its taken me a long time to come to this conclusion.

I have one major concern for functionality that needs to be replaced:

<pre>
include foo
$var = $foo::var
</pre>

I need some way of knowing that if a class has been declared, that I need to 
wait until its declaration is evaluated so that I can access variables from its 
scope.

note: since Jeff made this assumption above, I dont want the class to be in the 
scope where include is called, I just want to know that I can access variables 
from with-in its scope.

This is a massive change in the puppet language that will completely break 
backwards compatibility and require a rewrite of most people's code. Is it that 
much of a burdon to maintain include and ween people off of it slowly?

Also, so that everyone is on the same page, have we considered that this 
effects all things that rely on dynamic scoping:

* variables - behavior needs to change
* resource defaults - the previous behavior was not desirable
* stages - new feature, so it probably doesn't matter
* implicit tags
----------------------------------------
Bug #5046: Mixed invocation of parameterized classes leads to order 
dependencies, should be disallowed
https://projects.puppetlabs.com/issues/5046

Author: Paul Berry
Status: Needs design decision
Priority: Normal
Assignee: 
Category: language
Target version: Statler
Affected Puppet version: 
Keywords: parameterized_classes
Branch: 


When a parameterized class has default values for all of its parameters, it may 
be invoked using either "include" or "class { ... }" notation.  The "include" 
notation is idempotent; the "class { ... }" notation isn't.  As a result, there 
is an order dependency.  This works:

<pre>
class foo($param = defaultvalue) {
  notify { $param: }
}

class { foo: param => value }
include foo
</pre>

But this produces an error:

<pre>
class foo($param = defaultvalue) {
  notify { $param: }
}

include foo
class { foo: param => value }
</pre>

In large manifests, it is not always obvious (or even well-defined) what order 
statements will be executed in.  To avoid user confusion, I think it would be 
preferable if both these examples produced an error message saying something 
like "class foo already invoked using 'class { ... }' syntax, cannot also 
invoke using 'include'".


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" 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-bugs?hl=en.

Reply via email to