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.
For more options, visit https://groups.google.com/d/optout.
