Issue #5046 has been updated by Nan Liu.
Dan Bode wrote:
> I have one major concern for functionality that needs to be replaced:
>
> include foo
> $var = $foo::var
Initially I was going to disagree, but after testing I realize I can't access
any variable declared with class {...}. This is definitely a problem until we
have a replacement method to expose data:
class foo{
$var = "hello"
notice ("in foo")
}
class { "foo": }
notice ( $foo::var )
warning: Scope(Class[main]): Could not look up qualified variable
'foo::var'; class foo has not been evaluated
>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.
I'm not sure why required function was dropped, but I can live without it
(assuming the first issue is fixed). The example above invariably either exist
in another class or top scope. I would prefer it rewritten as a parameterized
class so the dependency is exposed.
class bar {
include foo
$var = $foo::var
}
node baz {
include bar
}
refacter:
class bar {
$var = $foo::var
}
node baz {
class { "bar":
require => Class["foo"],
}
}
or even better:
class bar ($var) {
...
}
node baz {
class { "bar":
var => $foo::var,
require => Class["foo"],
}
}
I consider this a positive change in the right direction.
> * variables – behavior needs to change
Dynamic scoping doesn't propagate, parameterized classes as interfaces,
improved decoupling.
> * resource defaults - the previous behavior was not desirable
We don't need to make any changes to resource defaults if we adapt the changes
above. The new class declaration makes them useful again since it isolates the
scope like defined resources. No more worrying about includes causing tight
coupling and affecting another class unintentionally.
----------------------------------------
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.
