John,
I have no disagreement with your statements. I've never done object
oriented programming professionally, and only dabbled with java to learn
some basics, so I guess I don't have as much bias in that regard...I really
thought I was just going with the terminology flow. The complexity of this
module comes with trying to extend it's use to various platforms. The goal
is to have the end user just "include complex" and get what's broadly
appropriate for that platform, while having the flexibility to exclude
specific components as needed. The module is implementing a system-wide
configuration policy and touches many aspects things that would normally be
done in individual modules. This is a policy thing similar to what the
SCAP Security Guide project might address. So if other modules are in
play, an end use could exclude or disable a feature in order to avoid a
conflict of multiple resource declarations.
David,
Currently, aside from using --strict, is what I am doing. I think what
made your explanations click most for me was referring to there being only
one value for a parameter. It seems a better approach to use the fully
scoped names, and including class parameters only in init.pp, than
attempting to include class params in the module's member classes (formerly
addressed as sublcasses).
Thank you both!
On Thursday, September 28, 2017 at 9:24:49 AM UTC-4, jcbollinger wrote:
>
> Dear Sean,
>
> David has already given you great answers to the questions you posed. I
> have nothing to add to those, but I feel inclined to nitpick your question
> a bit:
>
> On Tuesday, September 26, 2017 at 10:00:49 AM UTC-5, Sean wrote:
> [...]
>
>> The class arrays are strings of fully qualified subclass names, e.g. [
>> 'complex::redhat::subclass1', 'complex::redhat::subclass2', ] etc.
>>
>> Is there a benefit to actually using class params or declaring all
>> references to class variables directly as fully qualified in the subclasses?
>>
>> Here's a simplified example subclass, and yes the example is silly, if we
>> enable/disable a feature in puppet code, why not just exclude the subclass
>> altogether. Typically, that is what happens, but I was failing to find any
>> other simplistic examples to provide.
>>
>> class complex::redhat::subclass1 (
>> Boolean $enable_feature1,
>> ) {
>>
>> if $enable_feature1 {
>> notify("${::osfamily} Feature 1 is enabled")
>> } else {
>> notify("${::osfamily} Feature 1 is disabled")
>> }
>>
>> }
>>
>>
>>
>
> Puppet has subclasses, whose definitions can be recognized by their use of
> the 'inherits' keyword. What you are describing are not them. Even *bona
> fide* Puppet subclasses behave differently than most people tend to
> expect based on the uses of the term "subclass" in object-oriented
> programming languages, but the classes you are actually describing have
> nothing at all recognizable as a superclass / subclass relationship, in any
> accepted sense of the term. In particular, each of the classes you
> described defines its own namespace, separate from and independent of all
> the others'.
>
> The thrust of some of your questions suggests uncertainty about the
> relationship between those classes, which is an excellent reason to avoid
> use of the term 'subclass' for it. Even if you understood (and when you do
> understand) the relationship, describing it via the term 'subclass' is
> prone to confuse. In fact, one class having another's name as its
> namespace has very little practical significance, other than putting them
> in the same module. Even that is primarily organizational, not functional.
> I suggest just calling them "classes".
>
>
> 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/6cbc4f8b-809f-4e5e-b2da-830b0e012d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
