On 2014-06-08 8:25, David Schmitt wrote:
Hi,
thanks for keeping the ball rolling!
On 2014-08-06 02:51, 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: })
> The use case for number 1 is to provide determining the exact type of a
> resource at runtime. An example would be a module that had different
> implementations for debian vs redhat. It can then use parts of its self
> like so:
>
> apache::install::$osfamily { 'something': }
>
> Note: I'm not promoting this or saying that this kind of construction
> should appear everywhere, but it is a feature that isn't available in
> the language at the moment.
>
What Trevor said: highly prone to misuse, but for the use case given, +1
as a shortcut to create_resources.
Note: we talked about $ a having various types, but I think this
question only is about values that are Strings or Types, which I think
is a very sensible restriction to avoid the complexities and abuses
beyond the specified use case.
We came to a conclusion that a String or ResourceType result were ok. We
could however restrict this further to only accept:
* static NAME (i.e. an unquoted lower case name, like today)
* ResourceType (i.e. the result of evaluating Resource['name'], File, etc).
This restriction would force the user that wants type indirection to
place any string expression inside a Resource[], either on the LHS, or
when assigning to a variable. Maybe this restriction more clearly
reflects the intent?
i.e. these would be allowed:
file { title: ...}
Resource[file] {title: ...}
$a = "file"
Resource[$a] {title: ...}
$b = "ile"
$a = Resource["fi${b}"]
$a {title: ...}
File { title: ... }
$a = File
$a { title: ... }
but not these:
'file' { title: ... }
$b = "ile"
"fi${b}" { title: ... }
$a = file
$a {title: }
Maybe this restriction helps people from inadvertent use of a string,
and makes it easier to understand the intent, as a user/reader would be
able to trace the value of an expression back to a Resource[] type
expression (or even to a specific type reference such as File.
2. Whether to allow using hashes as resources parameters
3. If we allow hashes as resource parameters, what token introduces
it (no introducing token isn't an option because of implementation
constraints).
I really like Reid's suggestion to use a proper attribute name instead
of an asterisk.
I am fine with that too. (It reserves an attribute name though, but that
is not the end of the world).
[...snip...]
I do like both the defaults: title keyword and Reid's
'(attribute|param)_(override|defaults|hash)' metaparam instead of the
splat operator proposals. Both are shorthands for hash manipulation and
a create_resource call. In the most general sense, the whole Puppet DSL
is a shorthand for hash manipulation and create_resource calls. So for
me the questions is, are those shorthands understandable and valuable,
that is, more readable/modifyable/writeable than a hash+create_resource.
Like Trevor has suggested, we all might not be the best suited to reason
about this ;-)
I like that too.
I prefer 'attribute' prefix over 'param' (since parameters are declared
at the receiving side and the operation sets/passes attributes to the
params).
If we want both the "set" and "default" semantics, then I am slightly
concerned over the use of the "default" in yet one more place. Consider
something pathological like this:
type { default: attributes_defaults => $hash1,
attributes_hash => $hash2;
title1: attributes_defaults => $hash3,
attributes_hash => $hash4,
foo => 10;
title2: attribute_hash => $hash5;
}
Lots of defaults... If you really need defaults for a single resource,
it could be written in a separate body:
type { default: attributes_hash => $hash1 + $hash3;
title1 : attributes_hash => $hash4;
}
type { default: attributes_hash => $hash1;
title2 : attributes_hash => $hash5;
}
I think that is clearer. So, I think we do not need the
"attributes_defaults" special name.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lrtdlv%24aqv%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
