William F Pokorny <ano### [at] anonymousorg> wrote:
> -5 ==> ini keyword (cmd line flag ?) setting removed.
> -4 ==> lower case, shipped function looking like something inbuilt.
> -3 ==> deleted inbuilt function formerly defined in functions.inc.
> -2 ==> pseudo / hidden keyword removed.
> -1 ==> formerly visible and usable keyword removed.
> 0 ==> not now and never a keyword. Good to go.
> +1 ==> active SDL keyword.
> +2 ==> pseudo / hidden keywords active or potentially active on config.
> +3 ==> inbuilt function declared in functions.inc or cfunctions.inc.
> +4 ==> (povr never fakes inbuilt, lower case keywords with functions)
> +5 ==> current ini keyword (cmd line flag?) setting.
> (+-5 checking would be case insensitive)
> Actual keyword support in SDL is more complex because the meaning of
> keywords changes over time as functionality is added, removed or
> changed. Not thinking to try and document any of that drift in usage
> detail over time with keyword_status().
> The central aim is giving users a greater ability to check whether using
> any particular 'word' / 'keyword' in a scene has the potential to cause
> trouble or confusion.
I don't quite know what a few of those mean, but let me add some ideas here.
> The central aim is giving users a greater ability to check whether using any
particular 'word' / 'keyword' in a scene
has the potential to cause trouble or confusion.
Yes. And to that end, I would suggest a sort of stratifying - much like one
might do with memory, line-numbered code, or any other hierarchical structure.
So I don't really get why -5 is where it is.
I would probably use it (often) if I could run a simple
#if (keyword_status() > Threshold) check.
So one thing to think about would be to space the values out a bit, so that you
can fill in other things that come up as time goes on.
Post a reply to this message