On 4 July 2014 22:14, David Schmitt wrote:
> On 2014-07-04 18:31, Erik Dalén wrote:
>
>> Due to the dynamic scoping of them I only really use them for setting
>> global defaults. And some mechanism for doing that is really needed.
>>
>
> I've used to do that to set file buckets and Exec#path. But
On 2014-07-07 20:54, John Bollinger wrote:
On Monday, July 7, 2014 9:39:06 AM UTC-5, henrik lindberg wrote:
On 2014-07-07 15:43, John Bollinger wrote:
[...] Consider:
>
> class mymodule {
>File { group => 'example' }
> }
>
> class mymodule::example {
On Monday, July 7, 2014 9:39:06 AM UTC-5, henrik lindberg wrote:
>
> On 2014-07-07 15:43, John Bollinger wrote:
> [...] Consider:
> >
> > class mymodule {
> >File { group => 'example' }
> > }
> >
> > class mymodule::example {
> >file { '/tmp/example': owner => 'root', ensure => '
On 2014-07-07 15:43, John Bollinger wrote:
On Thursday, July 3, 2014 8:29:48 PM UTC-5, henrik lindberg wrote:
On 2014-03-07 22:57, John Bollinger wrote:
> Here's another idea: how about removing resource defaults
altogether?
> My take on them has always been that their dynami
On Thursday, July 3, 2014 8:29:48 PM UTC-5, henrik lindberg wrote:
>
> On 2014-03-07 22:57, John Bollinger wrote:
> > Here's another idea: how about removing resource defaults altogether?
> > My take on them has always been that their dynamic scope was their most
> > important feature. If tha
On 2014-07-04 18:31, Erik Dalén wrote:
Due to the dynamic scoping of them I only really use them for setting
global defaults. And some mechanism for doing that is really needed.
I've used to do that to set file buckets and Exec#path. But importing
modules really put a stop to that as I saw tha
Due to the dynamic scoping of them I only really use them for setting
global defaults. And some mechanism for doing that is really needed.
Using them inside classes is really mostly syntactic sugar to get the code
shorter. But I've also seen them used to conditionally set an attribute. So
not set
On 2014-03-07 9:40, David Schmitt wrote:
On 2014-07-02 21:55, John Bollinger wrote:
at the point where affected resources
are declared (for Lindberg-style defaults) or at the point where the
defaults themselves are declared (for Schmitt-style defaults, if I
understand that proposal correctly).
On 2014-03-07 22:57, John Bollinger wrote:
Here's another idea: how about removing resource defaults altogether?
My take on them has always been that their dynamic scope was their most
important feature. If that's going away then what's left is just a
minor piece of syntactic sugar, and keeping
On Jul 3, 2014, at 1:57 PM, John Bollinger wrote:
> Here's another idea: how about removing resource defaults altogether? My
> take on them has always been that their dynamic scope was their most
> important feature. If that's going away then what's left is just a minor
> piece of syntacti
Here's another idea: how about removing resource defaults altogether? My
take on them has always been that their dynamic scope was their most
important feature. If that's going away then what's left is just a minor
piece of syntactic sugar, and keeping them in that restricted form is
certain
On 2014-07-02 21:55, John Bollinger wrote:
at the point where affected resources
are declared (for Lindberg-style defaults) or at the point where the
defaults themselves are declared (for Schmitt-style defaults, if I
understand that proposal correctly).
My proposal would actually collapse thos
On Wednesday, July 2, 2014 7:41:18 AM UTC-5, David Schmitt wrote:
>
>
> John seems to have done more reading on this topic.
Henrik's description conflicted with what I thought I knew, so it made
sense to check the docs.
> If it turns out to
> be true that subclasses can change already se
On 2014-07-01 17:14, Henrik Lindberg wrote:
On 2014-01-07 8:52, David Schmitt wrote:
On 2014-06-28 16:54, Henrik Lindberg wrote:
...
What we want to do:
---
* Make application of defaults eager so that when a resource is
instantiated, it will immediately get the registered and visible
defaults
On Monday, June 30, 2014 8:11:47 PM UTC-5, henrik lindberg wrote:
>
> Need to correct myself... see below...
>
> What we cannot predict is what value will be set for realized resources
> that have an undef value for an attribute. Those are the only ones that
> can be modified with a Resource O
On 2014-01-07 8:52, David Schmitt wrote:
Hi Henrik,
On 2014-06-28 16:54, Henrik Lindberg wrote:
>>...
What we want to do:
---
* Make application of defaults eager so that when a resource is
instantiated, it will immediately get the registered and visible
defaults (for missing attributes), at
Need to correct myself... see below...
On 2014-01-07 2:24, Henrik Lindberg wrote:
On 2014-30-06 16:32, John Bollinger wrote:
On Saturday, June 28, 2014 9:54:25 AM UTC-5, henrik lindberg wrote:
* Make application of defaults eager so that when a resource is
instantiated, it will immed
On 2014-30-06 16:32, John Bollinger wrote:
On Saturday, June 28, 2014 9:54:25 AM UTC-5, henrik lindberg wrote:
* Make application of defaults eager so that when a resource is
instantiated, it will immediately get the registered and visible
defaults (for missing attributes), at *tha
On Saturday, June 28, 2014 9:54:25 AM UTC-5, henrik lindberg wrote:
>
> * Make application of defaults eager so that when a resource is
> instantiated, it will immediately get the registered and visible
> defaults (for missing attributes), at *that* point of time in the
> evaluation. This mean
19 matches
Mail list logo
