----- Original Message -----
>
>
> imho the right solution is a combination of the require and include
> keywords,
> resources requiring classes used extremely sparingly and the new
> syntax as Dan
> pointed out.
>
> What worries me greatly is that 'use parametrized classes' for
> everything
> recommendation
>
> I am a HUGE fan of param classes;) I find the dynamic scoping
> implications of include to be frightening and difficult to fully
> understand.
Sure I do like them too,
> seems to be the default response these days from PL even to the
> point of suggesting the include and require keywords be removed and
> deprecated
> while the alternatives are, to be frank, half baked.
>
>
> I agree that we cannot deprecate include until we fully consider the
> functionality that it provides and provide suitable work-arounds, I am
> also a little concerned about backwards compatibility, I hope we never
> pull a cfengine2->3
>
> The only two that I can think of are:
> - the ability to indicate a requirement for a class (all places that
> require a class can include it)
> - although the behavior this provides seems convenient, all of the
> implications with dynamic scoping and the fact that only a single
> inclusion path is chosen tp build the scope binding stacks based on
> code evaluation order makes it hard to fully understand from code the
> true implications of this
> - the ability to ensure that a scope has been evaluated so that we can
> access variables
>
> are there others?
>
class apache::php {
include apache
# do stuff
}
class apache($version="1.2.3") {
}
class{"apache::php": }
This will do what I want with apache as 1.2.3 etc simply saying i
want apache::php on the node will pull in the dependencies and just
looking at the apache::php class will tell me what will happend.
and if I want a different apache version:
class{"apache": version => "1.2.4"}
class{"apache::php": }
This lets me set a different version, without the include keyword you
cant do this cos you use the param class syntax twice
> I consider deprecating require moot, b/c we can express it as
>
> Class['self']->Class['other'] (unless there is something that I don't
> understand about require?)
do we loose anything by keeping the much simpler to read and understand
version? in addition to the more powerful and advance use version?
>
> :(, you can make regex case insensitive in puppet with (?i-mx:regex)
oh right, thats obvious. Principal of most surprising undocumented behavior
demonstrated :)
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users?hl=en.
