You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2019/02/27 18:15:59 UTC

[GitHub] ccollins476ad commented on issue #272: Fix expressions in settings restrictions

ccollins476ad commented on issue #272: Fix expressions in settings restrictions
URL: https://github.com/apache/mynewt-newt/pull/272#issuecomment-467971712
 
 
   I understand the value of this change, but I think it introduces some unintended effects.  Specifically, the value `0` is now valid for all settings (unless there is a package-level restriction that prevents it).
   
   For example, if I add the following restriction to the `SHELL_MAX_COMPAT_COMMANDS` setting:
   ```
       SHELL_MAX_COMPAT_COMMANDS:
           description: 'Max number of compatibility commands'
           value: 20
           restrictions:
               - SHELL_MAX_COMPAT_COMMANDS > 10
   ```
   
   In the current newt, overriding this setting with any value less than 10 triggers a restriction error.
   
   With the patch, values in the range 1-9 trigger the error, but a value of 0 is accepted.  As I mentioned, this can be worked around with a package-level restriction.  Is this behavior intended?
   
   I think the root problem is that the original restriction notation was implemented without enough thought put into it.  Now that we support more complex expressions, maintaining the old user-friendly notation is becoming more difficult.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services