>
> > 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?
> 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.
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?
-- Markus
--
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.
