Forum: CFEngine Help Subject: Re: Detriment to being explicit about "any::" ? Author: sauer Link to topic: https://cfengine.com/forum/read.php?3,23421,23515#msg-23515
jblaine Wrote: ------------------------------------------------------- > Those are silly trivialities in comparison to > bringing your entire infrastructure to its knees > by missing a class definition, which is something > that could very easily go right through unnoticed > in testing in a testbed with a complex > environment. Those are all stylistic issues which use structure to visually aid in preventing silly errors, including mandatory "all". Coding style guides don't exist just to give some lead developer a feeling of power. Never mind that a test environment which differs from production indicates a deficiency in test environment design - which is beyond Cfengine's scope to fix. ;) In any event, there's no religious war here. The question asked was intended to potentially help think through the impact of requiring an explicit class association for every promise. Does this vision extend to the attributes in compound bodies (COPBL, etc)? If so, that's a lot of extra typing for little gain. If not, why the inconsistency? And, if the goal is to make sure everything is explicitly tied to classes, should the existing "the last class applied applies until the next class is listed" policy also be removed - meaning that each individual promise would need to be explicitly prefixed with a class expression? If someone can overlook the default "any" class or completely forget to use a class expression, it seems just as likely that they'd overlook / forget the default "whatever class was last mentioned" behavior as well. So we end up with either an incomplete solution or, again, a solution which requires a /lot/ of extra typing for relatively little gain. I'm not a core developer, so I don't need convinced one way or another. However, these "how do you envision it working" questions need answered before making the formal feature request. The answers to those questions may also help in understanding why things work the way they work now. :) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
