On Tuesday, August 5, 2014 7:51:20 PM UTC-5, Andy Parker wrote:
>
> I'm pulling this discussion out into a new thread so that we can become
> more focussed. I'm also going to start a thread about one other topic that
> has been brought to my attention so that a decision can be reached.
>
> In this thread I'd like to get to a decision about two aspects of resource
> expressions:
>
> 1. Whether to allow expressions in the type position ($a { hi: })
>
Although I agree that there are potential uses, I do not like it, and I
would prefer for it to not enter the language. My primary argument is
basically Reid's: it makes the *DSL* more difficult to understand. I would
prefer to see defined types get a new automatic internal variable that
provides a hash of all the declared parameters for that instance. The
relatively benign example presented could then be expressed as
apache::install { something: }
define apache::install(param1, ...) {
case $osfamily {
'RedHat': { apache::install::redhat { $title: attribute_hash =>
$declared_attributes } }
'Debian': { apache::install::debian { $title: attribute_hash =>
$declared_attributes } }
...
}
}
Yes, it's somewhat more verbose, but it's also more explicit, and the
resource types involved are statically checkable. It's also a natural
progression from a hypothetical initial implementation of apache::install
that initially supports only one OS, or that handles multiple OSes all
internally.
Obviously, that also uses the proposed new feature of specifying attributes
of an ordinary resource declaration via a hash, but it seems clear that
that is going to be accepted in some form -- were just debating the details.
> 2. Whether to allow using hashes as resources parameters
>
As I said, I think were debating the details here, not whether this feature
will go in at all. I am fine with a meta-attribute, as I use in the above
example.
I think it would also be fine if an expression -- which must evaluate to a
hash -- were allowed in place of any explicit parameters. An explicit
parameter list is anyway a hash itself, though expressed in a slightly
different (because undelimited) syntax than ordinary hash literals. I like
this better for its logical consistency, and as a bonus it does not require
reserving any attribute name. I don't at the moment see any grammatical
issue with it.
> 3. If we allow hashes as resource parameters, what token introduces it
> (no introducing token isn't an option because of implementation
> constraints).
>
>
I'm not currently seeing what those implementation constraints might be.
Nevertheless, if there must be an introductory token then I like a reserved
meta-attribute such as the 'attribute_hash' I used in my example. Though I
did not use it, I think I rather like the idea of using an initial '@' in
the name (@attribute_hash) to distinguish this name from ordinary attribute
names.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/559c809d-f0e4-45f3-b387-8f4cb52e7c95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
