FWIW,
On Thu, Jul 24, 2014 at 8:32 PM, Andy Parker <a...@puppetlabs.com> wrote:
>
> DECISION TWO
>
> Resource instantiations are value producing expressions
>
> The expression based grammar that puppet 4 will be based on changed almost
> everything into a general expression, which allowed a lot of composition
> that wasn't possible before. This didn't change resource expressions.
> Resource expressions could not be assigned ($a = notify {hi:}). That is
> being changed. This removes several odd corners in the grammar and makes it
> all more consistent. It is also highly unlikely that it would be removed
> later (principle 1). The value of a resource expression is a reference to
> the created resource, or an array of references if there is more than one.
>
Very very cool.
> QUESTION: should the value always be an array of references? That would
> make it much more predictable.
>
I'm split on this. On one hand, for people who aren't really comfortable
yet with the new language features, it would be more straightforward to
have the result be the same as the input (title) type - i.e. if you didn't
pass it an array (and don't want to deal with iteration) you don't have to.
On the other hand, aside from truthy/falsy differences, I really don't like
it when dynamically-typed languages take advantage of that to return
different types like this - why make the user type check if they don't have
to. "This always returns an array" is easy to work with, especially if the
input might be a string or might be an array.
>
> DECISION FOUR
>
> The LHS of a resource *instantiation* expression can be an expression
>
> What?!? This means you can do:
>
> $a = notify
> $a { hi: }
>
> Once again, in clearing up odd cases in the grammar this is opened up to
> us. This is a very powerful feature to have available. Since this is very
> useful and fits well into the grammar I don't see this being a temporary
> thing that would then have to go away later (principle 1).
>
>
Agreed with Luke on this one. This scares me, and looks... not like Puppet.
I also can't think of a time that I was ever writing a manifest and
thought, "gee, I'd really like to make this a package or a service, but
sent either one the same params." (ok, I suppose I can see a use case where
I have 2 classes in my module that do more or less the same thing and take
the same params and I just want one or the other...)
>
> As a side note, do you see what can now be done?
>
> $a = notify
> $b = hi
> $c = { message => bye }
> $a { $b: *=> $c }
>
>
If I ever get a code review with "$a { $b: *=> $c }" in a .pp file, I'm
going to fire the submitter. In all seriousness though, having seen
manifests written by some people new to puppet (or looking back 3-4 years
in git history) I have some concerns about changes that could have such a
negative impact on language readability. The above ensures me that, at some
point in my career, I will see:
$a {$foo::bar::baz: *=> $blam::blarg }
Overall, very good work, and I can't wait to see how all this shakes out. I
know I've been a bit of a naysayer re: the language improvements. I suppose
if lint supports them properly and there are good docs on what not to do,
it's no big deal. My worries mainly revolve around (up to now) the
language's rigidity, which may have limited many of us, but also prevented
less experienced folks from doing anything *too* ugly/bad/unreadable.
-Jason
--
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/CAFt4V4kqqwZ%2BkAnUTsGeg4n%3DJo49G%2B0C0g4W-hNWRmOhcr79Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
