On Wed, Oct 23, 2013 at 12:44 PM, Rainer Gerhards <[email protected]>wrote:
> On Wed, Oct 23, 2013 at 11:27 AM, Pavel Levshin <[email protected]>wrote: > >> 23.10.2013 12:55, Rainer Gerhards: >> >> >> This code will execute correctly if msg contains either "tag1", "trag2" >>> or none of them, but will trigger an runtime-error if msg contains both >>> "tag1" and "tag2" (as it violates the constraint). >>> >>>> This restriction does not seem useful to me. >>>> >>> >>> Besides that you think it is not useful, do you think it hurts some use >>> case? Could you accept this restriction? >>> >>> >>> >> Yes, it does not change anything. You can always reformulate it as: >> >> >> if $msg contains "tag1" then >> set $.glob = "1"; >> >> if $msg contains "tag2" then >> set $.glob = "2"; >> >> set $/glob = $.glob; >> >> > OK, this was just a example. I am looking if someone sees anything that > will break potential use case. > > Just one other example where this may happen: > > set $/g = $/g + 1; > if $/g == 4 then > set $/g = 0; > > you can re-formulate this as > > if $/g < 4 then > set $/g = $/g + 1; > else > set $/g = 0; > > So it is not the perfect sample either. But I am thinking if there are > cases along these lines where we may get into troubles. > > >> But I still wonder what it's worth. >> >> > thought excerse. Let's first see if the relaxed condition can be used. If > not even the relaxed form can, than the more strict form is obviously much > less acceptable. > > But so to get more concrete, if you prefer: would it be OK if a state > variable could be accessed only once? Or would it cause trouble? Maybe I am > asking about the relaxed form because we already know that one-time access > gives us trouble: there would be no obvious solution for my example above > other than creating a specific sequence() function (what of course is a > solution, but the question is: can we get along with a less intrusive > approch)? > > So I am just trying to find some limits. As I said, after that I'd like to > think about actual implementation. > > Let me elaborate a bit more. Obviously, the problems with state variables occur only when they are update. If they were read-only, no problem would ever exist. But for some reason it makes very limited sense to have read-only state ;) So this would be too hard an restriction. Thinking along these lines, I wonder if things become easier if we at least limit the number of updates. One other restriction in this regard is A state variable cannot be modified after it has been accessed. Note that this is a far stricter restriction that "cannot be modified after it has been modified". It would make it impossible to write my above sample without the help of a specific atomic function, but it would still permit set $/z = $/z +1 write $/z which would not be permitted if we say "cannot be accessed more than once". How about that restriction? Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
