Redmine/6119

Eddy I think you are thinking too much like a programmer in this context. If the user has to handle error conditions in the language you're doing it wrong.

Cfengine's job is to fail safely not to demand logic programming of the user. I've seen people get tangled up over the inability to let go off micromanaging control when simple default behaviour would have been clearer.

As far as deleting item rather than using a null placeholder, If lists are to be empty when certain operations delete value values that needs a lot of expensive and fragile pointer arithmetic that serves no value other than saving you from no having "no value". It seems like expensive programmer thinking over cheap pattern thinking. CFEngine is supposed to be cheap to work with in my view.

Maybe I am just cheap. :)



On 10 Sep 2014 18:48, at 18:48, Edward Welbourne <notifications@github.com> wrote:
>> @@ -0,0 +1,16 @@
>> +body common control {
>> +    bundlesequence => { "cf_null", "test" };
>
>@cdituri - that would fit with the present state of play; but I'd very
>much prefer to avoid having any special handling of "cf_null" - or the
>invalid int "-678" or any other particular value of a data type treated
>as invalid value (despite being a perfectly valid value other than this
>fiat) so as to serve as an indicator that something went wrong.  Errors
>should be indicated some other way.  As for empty lists, they should be
>represented by *being empty* - not by having a special entry that we
>ignore, causing endless complications where we concatenate lists,
>filter them, format them and so on.  Still, as long as we're going to
>treat "cf_null" specially, we do indeed need to do so consistently and
>raise errors, as you suggest, rather than silently ignoring what the
>user explicitly said.
>
>@markburgess - I'd need to see more details of the situation in which
>you were doing that, but that one sounds suspiciously like a case where
>a specific value can safely be used as error indicator for *this
>particular use* without having to complicate the *language design* by
>having the language treat one otherwise good value as invalid.  Using a
>dummy value (e.g., in a table of IP addresses, something patently
>incapable of being mistaken for an IP address) is perfectly fine *in a
>particular use case*, where that dummy can't naturally arise otherwise,
>but doing it globally just creates problems.
>
>If someone ever needs to represent the integer -678, they're out of
>luck.
>
>Policy language has the clearly-defined concept of a promise not kept;
>and it formalises setting of variables as promises that the variable
>gets a value; so the correct way to represent "did not get a value" is
>for the "set this variable" promise to fail and for those trying to use
>the variable's value to test whether that promise failed.  Having the
>variable successfully set - promise kept ! - but to a value reserved to
>mean "bad value", even though this value could in fact arise naturally
>as a good value - fails to leverage what the language is good for.
>
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/cfengine/core/pull/1978/files#r17373121