This is what I do. This way the sub-classes automatically get variables
defaults from the parent-class and when using the module you should only
have to call the parent class; as long as you have defined all your
parameters that are used by any sub-model in the parent class.
class module (
$var0 = $::module::params::var0,
$var1 = $::module::params::var1,
) inherits ::module::params {
include module::file
include module::package
}
class module::file (
$var0 = $::module::var0
) { }
class module::package (
$var1 = $::module::var1
) { }
On Wed, Sep 17, 2014 at 7:49 AM, jcbollinger <john.bollin...@stjude.org>
wrote:
>
>
> On Wednesday, September 17, 2014 3:15:44 AM UTC-5, François Lafont wrote:
>>
>> Le 17/09/2014 04:26, Sebastian Otaegui a écrit :
>> > As far as I know "inner classes" are an anti pattern(for the lack of a
>> > better term)
>> >
>>
>
>
> Nested classes are poor form, but multiple classes in the same module are
> fine.
>
>
>
>> > Each class should live in its own file.
>> >
>> > More than one class per file is discouraged
>>
>>
>
> More specifically, nesting classes or defined types inside other classes
> is widely considered poor form these days, and it *will* cause you grief
> unless you know exactly what you're doing or you get very, very lucky.
> Putting multiple un-nested classes or definitions in the same file (or
> otherwise arranging classes and definitions differently than the autoloader
> is prepared to handle) is even worse form, and even if you know what you're
> doing you probably cannot make that work smoothly without resorting to
> near-deprecated 'import'.
>
>
>
>> I agree. It's better to define "inner classes" in separate files
>>
>
>
> I prefer the terminology "module classes", as distinguished from the
> "module main class" or "main module class". The term "inner class" carries
> too much baggage, and anyway, sometimes module classes are not intended to
> be private to the module.
>
>
>
>> (my_module::internal1 in my_module/internal1.pp, my_module::internal2
>> in my_module/internal2.pp etc).
>>
>> But this is not really my question. My question is: which pattern should
>> I use:
>> a) to define inner classes (indeed in a specific file)
>> b) and to call inner classes in the "my_module" class (which is the
>> "top level" class called by the user of my_module)
>>
>> knowing that a inner class needs to use variables defined in
>> my_module::params, but among these variables, maybe severals
>> variables are parameters of the my_module class with a different
>> value of the default value proposed in my_module::params.
>>
>>
>
> Do not get hung up on class inheritance, and especially do not confuse the
> usage of the terms "class" and "inheritance" in Puppet context with the
> usage of the same terms in OOP context. Puppet classes are not classes in
> the OO sense, and Puppet class inheritance has significant dissimilarities
> from typical OO class inheritance.
>
> Moreover, with respect to your actual question, it is important to
> understand the purpose of class inheritance as it applies to the params
> class pattern: its *only* purpose in that context is to ensure that the
> ::params class is evaluated (and thus its variables assigned their values)
> before the parameter list of the inheriting class is evaluated. That makes
> it safe for variables of the ::params class to be used as class parameter
> defaults in the inheriting class. Note, too, that that effect is merely a
> side effect of class inheritance, not its true purpose.
>
> If a given module class uses variables of the module's ::params class, but
> none of them as (its own) parameter defaults, then it can 'include
> my_module::params' in its body instead of inheriting from the params
> class. If a module class does use ::params class variables as default
> values for its own parameters, however, then it should inherit from the
> params class both for documentary and for self-containment purposes.
>
>
>
>> For instance with:
>>
>> class my_module (
>> $var1 = $my_module::params::var1,
>> $var2 = $my_module::params::var2,
>> $var3 = $my_module::params::var3,
>> ) inherits my_module::params {
>> # The body of the class
>> }
>>
>> and:
>>
>> class my_module::params {
>>
>> ## API of the module ##
>> $var1 = default_value1
>> $var2 = default_value2
>> $var3 = default_value3
>>
>> ## shared variables between the classes of my_module
>> ## but they are not part of the API module
>> $foo1 = default_value_foo1
>> $foo2 = default_value_foo2
>> $foo3 = default_value_foo3
>> ...
>> }
>>
>> Imagine I want to define an inner class "internal" which
>> needs to use $var2, $var3, $foo1 and $foo2. Which pattern
>> should I use to define my "internal" class.
>>
>> This one?
>>
>> class my_module::internal (
>> $var2,
>> $var3,
>> ) inherits my_module::params {
>>
>> notify { "value of foo1 -> $foo1": }
>> notify { "value of foo2 -> $foo2": }
>>
>> }
>>
>
>
> No, if only because you are using the variables $my_module::params::foo1
> and $my_module::params::foo2 without qualifying their names. It works, but
> it is poor form. In this particular case it is also confusing, because
> class parameters $my_module::internal::var2 and $my_module::internal::var3
> have the same unqualified names as variables of class my_module::params,
> but they are completely separate variables.
>
>
>>
>> This one?
>>
>> class my_module::internal (
>> $var2,
>> $var3,
>> ) {
>>
>> require my_module::params
>> notify { "value of foo1 -> $my_module:params::foo1": }
>> notify { "value of foo2 -> $my_module:params::foo2": }
>>
>> }
>>
>>
>
> It would be better to use 'include' than 'require' in this case, and you
> mis-typed a couple of your namespace separators, but basically that's fine.
>
>
>
>> Or maybe another one...?
>>
>>
>
> You could also do this:
>
> class my_module::internal (
> $var2,
> $var3,
> ) inherits my_module::params {
> notify { "value of foo1 -> $my_module::params::foo1": }
> notify { "value of foo2 -> $my_module::params::foo2": }
> }
>
> I'm not a big fan of the ::params class pattern in the first place, but if
> you use it then there is some maintenance advantage in keeping all your
> code consistent that way.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/a76e0b14-9719-4d18-843c-6ecea3ec1e3e%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/a76e0b14-9719-4d18-843c-6ecea3ec1e3e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAF-H%3DOkTk4E3i%3DnP9qrXHYandV92fWCdiR6wLULYnzHr6CtRsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
