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 <[email protected]>
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 [email protected].
> 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 [email protected].
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.
