On Fri, Dec 16, 2011 at 09:34:12AM -0500, no-re...@cfengine.com wrote: >This is an excellent discussion.
I concur. >Class scope should be clear and defined. I don't like the idea of loosening >this. It reminds me of the looseness of PHP and the breaches it caused. >Don't go for the quick and easy fix. You mean common vs bundle scope here? Ditto with variables, I'd suggest, although this has been discussed elsewhere. >With regards to anonymous subroutines, or inline body parts if you prefer. >Both sides have a point but, I agree with Mark. The suggested changes look >nice from a programmer's point of view. However, I don't like treating >Cfengine syntax as a programming language. I see many examples of that and >the results are mostly unreadable. Add in line body parts and we'll be back >to the very long promises we hand in Cfengine 2. When we first start we >usually view the body parts with apathy. They seem tedious and unnecessary. >However, once we have a good library of body parts under our belt we usually >forget about them. In exchange promises are short and easy to read. I should clarify that I do *not* think that long inlined promises are a good idea. Mark's example of a promise whith a long list of ignore=* statesments is a good example. I understand, and like, having a rigid "API" for using bodies in various places. My main issue is that you have to make full duplication of various bodies to make what I think are minor changes. For example, if I want to assert N classes, that requires almost full duplication of a body to define N+1 classes, which is different from N-1, N+2, etc... In my experience, any time you have to start doing things like "thing1" and "thing2", you're doing it wrong. It's one thing to have a good library of body parts. It's quite another to have a large library of bodies that are fundamentally similar to each other because they are all minor variations on each other. >"Let us change our traditional attitude to the construction of programs. >Instead of imagining that our main task is to instruct a computer what to do, >let us concentrate rather on explaining to human beings what we want a >computer to do. " -- Knuth. So why not, to pick a specific example, allow for more flexible, but *unambiguous* and *consistant* language constructs? If the point is clarity, duplicating code isn't a solution, and I've seen a number of examples of people jumping thorugh syntaxtic hoops to accomplish something that could be much simpler (and still "clean/pure/etc"). >Which brings me to data structures. I agree that the current batch leaves a >bit to be desired. I avoid using more than a list because I find them so >difficult to follow. I'm all for improving them for better function and >readability. > >In template file promises I would like to see lists other data structures work >with them. I do not agree that the required two promises is too much to bear. > Yes, you have to cache the template file. I suggest caching all files anyway >in order to survive communication loss with the policy host. The alternative >is a files promise for every iteration of the promiser file. At that price >the current template file method is a good bargain! This is all good, but why does it need to be broken up? You're templating. Make caching the intermediate file automatic. If you really want to maintain twice the promises, that's still certainly possible. >Which brings me to efficiency. When you start to work with very large >policies Cfengine 3 does noticeably slow down. The slow down is not a show >stopper but, for a C program we know this should not happen. I'd like to see >a major effort on the part of Cfengine developers towards large scale >performance tests to fix these issues. Better timestamps in the logs would allow for better profiling. Of course, profiling the code would do much the same. ;-) -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
