On 2014-18-07 19:33, John Bollinger wrote:
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 |>
yes, it could, realize is a function that may be called without parentheses.
? 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.
We are thinking about a new kind of query mechanism. This because
changing semantics of the current mechanism is going to cause lots of
breakage.
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.
These are indeed the kinds of things we want to be able to do.
Priority wise, we are first going to reimplement the collection
mechanism in such a way that we can delete the old code it depends on.
Later (after 4.0) we are going to be working on the new catalog builder.
What we want to ensure now is that we make the necessary grammar changes
to the language that makes it possible for us to gradually introduce
these new features.
- 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/lqbtln%24dg8%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
