On 12/02/10 19:58, Markus Roberts wrote:
>>
>>> Options at this point:
>>>
>>> * rebase onto the present end of testing
>>> * wait until Luke's branch merges cleanly and my stuff (including string
>>> interpolation) is stabler
>>> * rebase onto a commit right before the futures stuff (such as
>>> b4e4de350a51bc1b362cc7d134d86d
>> aa33a99765) and making dealing with the issues
>>> listed above it my problem (this is the option Luke is taking with his
>> #2954
>>> stuff)
>>>
>>> Any of these is fine with me, though I'd prefer the first or the third on
>>> the principle of getting stuff in early so we can resolve the conflicts.
>>
>> For simplicity I'd like 3), but I need your string interpolation patch,
>> so I guess that'd be 2). But that doesn't mean I can rebase now and try
>> it for fun.
>>
>
> So 3) (rebasing on a point before my stuff) should be possible without the
> string interpolation stuff, right? Or am I misunderstanding?
You're correctly understanding (I'm tired tonight). Indeed 3) is perfect
because I expect the string interpolation of hash access would work
directly.
I will fetch testing and rebase before your patch.
>> Does your future stuff works only for variable value, or does it also
>> covers resources (it doesn't seem so)?
>> I'm asking this question, because when I first submitted the hashes
>> patch, one of Luke's comment was to also support getting resource
>> parameters through the same syntax (which fired the start of your future
>> work).
>
>
> The short answer is probably a member of { yes, no, maybe, mu, uh...hmmm }
> but that probably isn't a useful response.
>
> The futures just deal with values, without regard to what those values might
> be. They abstract out (via a layer of indirection) the notion of order of
> evaluation; a future can be manipulated (passed around, stored, whatever)
> without regard to whether or not its value (or even its source) is known.
Yes I get how futures work (I mean in general, I already used some in
some of the java projects I worked on).
> In the context of resource parameters, this means that (subject to "all
> those tiny little details" and a few caveats) we could manipulate resources,
> resource parameters, or whatever in the same way. A few of the
> details/caveats off the top of my head:
>
> * While the present system abstracts over the evaluation time of _values_ it
> expects names and scopes to be resolvable as soon as they are seen. It
> would not be possible, for example, to set the parameters of an
> as-yet-to-be-identified resource or set the value of a to-be-determined
> parameter of a given resource with the present system.
> * Validation code might have to be made futures-aware; this could be
> anywhere from trivial to daunting.
> * This system uses explicit futures (the user has to call value explicitly)
> but it could be converted to one with implicit futures (sort of like ruby's
> WeakRefs) if it gets too messy.
> * Right now futures have to resolve "directly"; we may want to consider
> supporting futures that resolve to other futures (or more usefully,
> structures containing them). Looking at the use cases for addressing
> resource parameters may be useful in determining if this is needed or not.
>
> Does that answer your question, or make it worse?
Thanks for the information. I think I won't add resource parameter
access in the hash patch, looks like it's much more than I can provide :-)
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en.
