On Friday, July 11, 2014 9:50:47 PM UTC-5, henrik lindberg wrote:
>
> On 2014-11-07 10:55, David Schmitt wrote:
> > [...]
> > * 'Type<| expr |>' is the list of local resources of type 'type' in
> > the current compilation where 'expr' evaluates true. As a
> > side-effect, it realizes all matched virtual resources.[1]
> Some sort of query operator. If we keep the <| |>, it could mean
> selection of the "virtual here" container/subset, currently it is
> "everything defined here".
>
[...]
>
> > [1] It might be worthwhile to start requiring to always write
> > 'realize(Type<| expr |>)' for this side-effect.
You are by no means the first to suggest that conflating realization of
virtual resources with selecting a collection of resources was a poor
idea. With the much higher profile that collections have nowadays, I think
that is becoming a more pressing issue.
> > This looks annoying.
>
> it could be
>
> Type <| expr |>.realize
>
>
Couldn't it also just be
realize Type <| expr |>
? I mean, at least some Puppet functions already do not require
parentheses around their arguments under some circumstances (e.g.
include()). It makes more sense to me to put the function name / keyword
first, but the parentheses are optional as far as I am concerned, and it
reads more cleanly without them.
Alternatively, perhaps there can be a new selection criterion that limits
collections to resources that are in the catalog (at the time the
collection's contents are determined). That would allow current collector
semantics to remain the same, while still affording manifest authors the
ability to collect resources without realizing still-virtual ones. The
same or similar criteria could be used to narrow results to other
categories of resources.
Also, long ago I made a feature request that collections be usable as
r-values. My main idea for that was to be able to assign collections to
the relational metaparameters, and that purpose is now served by chain
expressions instead. Still, I suspect there are still other uses for
collections as r-values, and it sounds like that may be one of the
directions this is going. If that can be made to work smoothly, then it
would be pretty cool. On the other hand, I don't have specific use cases
in mind, so I wouldn't personally consider this a priority, and maybe not
even a real candidate for implementation.
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/78ba2133-5f94-4625-b6bf-04edd4e0b1f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
