On Tue, Jun 25, 2013 at 9:45 AM, Andy Parker <[email protected]> wrote:
> On Mon, Jun 24, 2013 at 11:04 PM, Dean Wilson <[email protected]>wrote: > >> On 29 April 2013 08:46, Luke Kanies <[email protected]> wrote: >> >>> No - that's more about running a given chunk of code periodically, but >>> not informing the user specifically, and I think what Dean is more looking >>> for is a reminder to the user to delete some configuration code that's no >>> longer relevant. >>> >> >> That's exactly it. >> >> I no longer work with the people that use this metaparam so I've got no >> major investment in which implementation approach to take but I'd like to >> finish it off for the next time it comes up. >> >> I agree with Dustin that a function in stdlib would cover the class >> level thing but I think a metaparam is still the way to go for finer >> grained deprecations. I'm happy to write a function based version for now >> but I'd be interested in peoples view of the metaparam approach. >> >> > I'm torn on this. I like being able to communicate in the code that > something shouldn't be used anymore and a metaparam seems like a good way > to do that. On the other hand, a metaparam also shows up everywhere and > takes up some of that precious namespace of type parameter names (of course > a type takes up names from the class namespace and a function takes up > names from the function namespace). So if what we are looking for can be > achieved through other means, then that might be better and more flexible > for the future. A metaparam has a feeling of permanence. > I've used a metaparameter called 'transport' to specify connectivity for resources managing remote APIs. A function would not work in this case. I can see how this becomes a problem and create conflicting modules. The fall back is to specify the transport parameter on every custom resource type (about 70). I'm certainly open to better options if you have another recommendation. Thanks, Nan -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
