On 2014-03-08 22:18, Luke Kanies wrote:
On Jul 28, 2014, at 6:43 AM, John Bollinger <john..bollin...@stjude.org
<mailto:john.bollin...@stjude.org>> wrote:



On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote:


    We reasoned that we already have create_resources in frequent use to
    solve real issues, so it is needed. I don't think create_resources is
    used simply because you can. Instead, it is because you do not
    statically know the type, or you want to decide which attributes
    to set
    based on calculations you made. Both of those require
    create_resources
    function. Now it moves into the language.



For what it's worth, every use of create_resources() that I have ever
come across or thought about has involved a resource type that is
statically known.  The usual reason for create_resources() is that the
*identities* and properties of the resources need to be dynamically
determined.  That is, if I need or want to resort to
create_resources() then it's /usually/ because I don't know statically
which specific resources (of a known type) need to be managed.
Sometimes I /also/ don't know which properties need to be managed or
maybe what their target values should be, but that's secondary.

Exactly.  This is the more normal case, and is the one we should
optimize for.  And, IMO, the one that create_resources works just
dandily for.  I don't see the need to promote a function to syntax in
this case.

    >
    > "*=>" looks weird, even for Puppet.  What about contracting it
    to "*>",
    > parallel to the plussignment operator (+>) and to the ordinary
    value
    > binding operator (=>)?
    >

    The rationale is that you normally have:

        name => value

    Now, you do not have names, and * is often used as a wildcard/splat/
    "split it up", implied, the name is picked from the hash, and you may
    want to line them up:

    file { default:
              *    => value ;

            foo:
              mode => '0777' ;
          }

    Does that make it feel better?



Somewhat, yes.  I at least get the mnemonic angle, but it still seems
weird.

Is this one operator "*=>" or two "*" "=>"?  If one, then are you
really going to permit splitting the operator into two tokens?  If
two, then is this splat operator the same one you described
elsewhere?  And what is the splat's operand in this context?

With this new, highly expressional approach, it seems like there
should be a way to do without the *=> altogether.  I mean, if you have
a property name / value hash, then why shouldn't you be able to plunk
it down undecorated inside a resource instantiation expression?  E.g.

file {
  default:
    $file_defaults;
  foo:
    mode => '0777';
}

or

file {
  default:
    $general_file_defaults,
    owner => 'ted';
  foo:
    mode => '0777';
}

or even

file {
  default:
    $general_file_defaults,
    $mymodule_file_defaults,
    owner => 'ted';
  foo:
    mode => '0777';
}

Yeah, I'm not at all a fan of the '* => foo' syntax.  It seems strange
in both the lexer and the parser, and it strikes me as a far large
change to the system without a large return.


It was trivial to implement. There was nothing difficult about this in the lexer / parser. The '* =>' is actually two tokens (nothing was added in the lexer to support this).

If we conclude we need significantly more power in the resource
parameters, then I'd prefer to do something like formally treat it as a
hash, and support some kind of hash operations there.  E.g., something like:

file {
   default:
     $some_defaults + $other_defaults + {owner => 'ted'};
   foo:
     mode => '0777'
}

The splat rocket works for all titled resources, not just default.
And it is formalized to accept a hash where the keys must be valid as names of attributes.

This expands how we think about the RHS of a resource declaration, but I
think it's more generically powerful and requires far less specialized
syntax.


Sorry, but it is actually less powerful, and requires more specialized handling in the grammar. When using a token that indicates that "here follows a hash of attribute-name to value mapping", it is much simpler.

Have any other suggestions to replace '* =>' ? Almost anything that is not already a valid unary operator (i.e. !, *, +, -) or significant punctuation (, . ; : { } [ ] ( )) could be used (or combination of tokens, like the now implemented '* =>')

Here are some that have come up:

file { default: => $hsh }
file { default: *> $hsh }

- 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/lrme16%246tf%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to