On 21 Sep 2017, at 4:17, Jan Grashöfer wrote:
> While I agree that there are two (more or less) distinct groups and > that > the notion of configuration should be separated from the notion of > brogramming, I don't think that anyone would profit from introducing > something like &config="just.another.name". Because of the additional > name mapping, this will make scripts harder to understand for > brogrammers (especially for beginners), whereas the benefit for users > would be minimal. I don't think that this proposal makes scripts any harder to understand for programmers than things are currently. From a programmers perspective, they would still use variables the same way they currently do. The only difference is that a user might not be using redef to change values, but the programmer doesn't see that happening anyway. It also doesn't change anything about what configuration values the programmer makes available since the programmer is already forced to expose their configuration through the export section. >> Invariably, there will be variable names chosen within software that >> will be short and convenient or long and explanatory but may not end >> up >> being just right if someone simply wants to configure a behavior. > > I think that would just be bad coding style. That's a fair statement. In an ideal world, all programmers would name their variables perfectly. I know that the opportunity for poor naming is still present with the &config attribute value, but for me at least, it puts me in a different frame of mind because this is the name that I'm exposing to users as a configuration option. It almost forces people to step out of the programming mentality. > So that is definitively a valid point! But instead of coming up with a > "new language element" I would prefer to add support for multi-level > namespaces into Bro. Yes, please do this! :) > That all said, what's about the poor users? Instead of throwing a huge > config file of key-value-pairs at someone who does not know about the > internals of the corresponding scripts, I would provide a UI to them > (maybe someone comes up with a bro-package...). The UI could display > all > options in a structured way and further support configuration by also > showing the corresponding documentation for each option. This would > allow a clean cut between users and brogrammers without intermingling > both worlds. Yep, this notion of making things abstract-able into easy configuration interfaces and/or good documentation (using the inline broxygen comments) was always in the proposal, Johanna pointed it out in the original code sample. There is just something about the idea of exposing variable names to users (even if it's wrapped in a gui) that is intensely unpalatable to me. It's pretty much unheard of among other types of software. It would be like exposing internal variable names to command line programs instead of abstracting it into easy flags (i.e. -a or --help) or, if in a gui a text entry box had a label next to it like "GUI::My_Program::user_name" instead of showing "Username". Sometimes abstraction like this isn't warranted, but I think it has to be done here. Bro needs to turn into a platform that treats users as first class citizens in the community and we need to acknowledge that there will be a day that they won't be reading script source code and they won't want to be exposed to programmer-isms. .Seth -- Seth Hall * Corelight, Inc * www.corelight.com _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
