RFC: Remove resource default support for classes?

[Henrik Lindberg]

Next up in the quest to understand and specify how defaults work /
should work is the support to set class parameters via the resource
default expression.

You can do this, to set defaults on classes

class a ($x) {
notice "The x is $x"
}
Class { x => 'the default' }
include a

The output is "The x is the default"

This is a very blunt instrument as it is not possible to define the
defaults for a particular class. And (drumroll), it is almost useless as
the parameters specified must be parameters that exist in *all classes*.

The only possible meaningful use of this is to set meta parameters such
as `audit`, or `loglevel` on every class.

Can we remove this support?

If there are reasons to keep it, can we specify it so that it is only
allowed to do this for meta parameters? (We can then statically validate
this and give errors at parse time as opposed to runtime when
a default expression may be conditionally evaluated and blow things up
under certain conditions).

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[John Bollinger]

On Friday, July 4, 2014 9:42:00 AM UTC-5, henrik lindberg wrote:

Next up in the quest to understand and specify how defaults work /
should work is the support to set class parameters via the resource
default expression.

You can do this, to set defaults on classes

      class a ($x) {
       notice "The x is $x"
      }
      Class { x => 'the default' }
      include a

The output is "The x is the default"

This is a very blunt instrument as it is not possible to define the
defaults for a particular class. And (drumroll), it is almost useless as
the parameters specified must be parameters that exist in *all classes*.

The only possible meaningful use of this is to set meta parameters such
as `audit`, or `loglevel` on every class.

Can we remove this support?

Dressing classes in resource clothing doesn't make them resources.  Neither, really, does using some of the same abstractions to represent the two, except in a rather technical sense.  At the DSL level, Puppet classes have always had substantially different semantics from bona fide resources, and that this question even arises springs from a steadfast and well-intentioned, but less-well conceived, attempt to ignore that.  This is not at all the only area where ignoring the distinction causes trouble.  Resource-like class declaration syntax should never have been introduced.<descend from='soapbox'/>

TL/DR: tear it out -- we never should have had it anyway!

John