>> Hmm, another alternative would be to hook an ephemeral scope hierarchy
> >> to the current scope; evaluate_match would then spawn a new ephemeral
> >> scope which would "alias" the previous one in the same scope. That would
> >> be the cleanest solution.
> >
> > It might also violate the principle of least surprise. What would you
> expect:
> >
> > $var = "matchagain"
> > case $var {
> > /match/: {
> > notice($0)
> > if $var =~ /matchagain/ {
> > notice($0)
> > }
> > notice($0)
> > }
> > }
> >
> > to produce?
>
>
clearly:
> match
> matchagain
> match
>
> Explanation:
> /match/ -> creates an ephemeral scope containing $0 == match
> =~ -> creates a child ephemeral scope containing $0 == matchagain
> out of if -> pops the last child ephemeral scope
> last notice sees match
>
Note that the ruby equivalent:
$var = "matchagain"
case $var
when /match/:
puts $~
if $var =~ /matchagain/
puts $~
end
puts $~
end
produces:
match
matchagain
matchagain
since there isn't really a scope difference (ruby has closer to the behavior
you'd get with the submitted patch).
> But unfortunately the following will not work
>
> case $var {
> /match/: {
> if $var =~ /matchagain/ and $var =~ /aslomatch/ {
> notice($0)
> }
> notice($0)
> }
> }
>
> Because both =~ will spawn a new ephemeral scope, but out-of-if might
> not kown how many ephemeral scope were created, except if it keeps the
> number somewhere, which looks ugly (ie keeping state out of the scope).
>
> Any better idea?
>
*laugh* This is not a good week to ask me for better ideas. I'm more
working in the grumbly objections space.
After doodling some circles with lines and arrows and stuff I've come to the
tentative solution that we don't have a well defined scope transition
anywhere in there that will work (note, for example, that the condition is
evaluated in the outer scope, not the inner, which doesn't/wouldn't exist
until we know the results of the condition.
The real problem is that "ephemeral variables" aren't compatible with the
idea of a declarative language, in that they rely on an order of execution.
Not holding them to the single assignment rule at least makes for a clean
fix and is a start to the disentangling. The "real" solution would probably
be to do something like this under the covers:
case true {
($ephems_1 = re_match($var,/match/)["$0"]: {
if ($ephems_2 = re_match($var,/matchagain/)["$0"] and ($ephems_3 =
re_match($var,/aslomatch/)["$0"] {
notice(ephems_3["$0")
}
notice(ephems_1["$0"])
}
}
where the $ephems_x are single assignment hashes that store the results of a
specific match and the uses are statically tied to the defining case, but
I'm not up for making that change at the moment.
-- 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.
