So, I care some about this: pretty much every place we want to do this
feels very, very much like a work-around to the inability to interact
with meaningful information through either recursion, or iteration, in
the Puppet DSL.  People end up contorting around like snakes to try
and figure out some way to work around other shortfalls of the
language and wind up here.

In my view, rather than creating a second, entirely parallel syntax
for the Puppet DSL to express resources, we should identify what the
individual underlying problems are, solve them, and keep an overall
simpler and cleaner system.

...and, yes, I *do* think that having the ability to use either a
hash, or a resource, to model a resource is creating a second, shadow
language for Puppet resource declaration.

Daniel

On Mon, Jun 13, 2011 at 10:18, Randall Hansen <[email protected]> wrote:
> I think Aaron lays out the options pretty well.  This issue has been
> hanging fire for quite a while, and it would be nice to come to a
> decision about what our path forward is.
>
> Who else cares about this?  What do you think?
>
> r
>
> On Wed, Jun 8, 2011 at 1:36 PM, Aaron Grewell <[email protected]> wrote:
>> We've looked at two different possibilities thus far:
>>
>> 1) Make all resource types hash-aware.  This is what I was originally asking
>> for.  It would mean changing the way resources are declared so that in the
>> case of a hash their representation of $name was appropriate for use with
>> defines and virtuals.  This could either be done by requiring the hash to
>> have a 'name' key and using that or by creating a metaparameter like
>> hash_key so it could be user-specified.  The hash itself would need to be
>> passed to the resource in the same way as $name but with a different
>> identifier so that its keys could be accessed inside the resource as e.g.
>> $data[key].
>>
>> The upside of this is that it should work universally and conceptually match
>> the rest of Puppet, the downsides I see so far are that its implementation
>> might well be intrusive and it might also add to the DSL.
>>
>> 2) Create a hash -> resource transformation function.  If I understood John
>> correctly this is what he was in favor of.
>>
>> The upside of this is it should be less intrusive, easier to implement, and
>> require no DSL changes.  The downside is that it still makes hashes special
>> and requires separate handling of them.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>
>



-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <[email protected]>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to