Am 14.06.2021 um 15:37 schrieb William F Pokorny:

> Reality is less clean. I don't know the history, but take the 
> #breakpoint parsing code enabled strictly with POV_DEBUG. It effectively 
> changes the parser a little in enabling a new keyword for 'developers.'

That feature is actually a very good example of stuff that should ALWAYS 
be enabled in developer debug versions, but NEVER in a hypothetical 
"end-user debug versions" (except for a dedicated developer debug 
version thereof).

The keyword is intended to flag lines in the scene file, and set debug 
breakpoints anywhere in POV-Ray's code that only trigger if the parser 
has already passed that line.

> Fresh in my mind because it's use shifts internal identifier enum values 
> due being inserted as a new keyword for POV_DEBUG builds. I've been 
> refining povr's new id_type() function and it's more or less the straw 
> which prodded me to create a core shipped 'setidtypes.inc' include file 
> when I'd intended to leave that job to users.

Yes, it's a very bad idea to expose any of those constants to the end 
user. The values WILL be subject to change WITHOUT notice. There are 
documented constraints to the list that would conflict with a policy of 
"keep this list frozen forever, only ever appending to the end", even if 
we were to ditch the "please keep this sorted alphabetically" policy.

It's even a very bad idea to try and catch them with hard-coded values 
in a `setidtypes.inc` to be shipped with the source, because they may 
even vary in DIFFERENT BUILDS of the SAME VERSION - even not considering 
debug versions. Most notably, future versions may include certain 
experimental features, that might require certain preprocessor switches 
to be enabled. Look at `POV_PARSER_EXPERIMENTAL_OBJ_IMPORT` for an example.

For a smarter approach, consider designing a syntax to look up the 
values by associated keyword, rather than hard coding them. Or by 
probing constructs of known type.
(If you're already doing that, forget I said anything. I haven't found 
the time & energy to have any closer look at your implementation of that 
feature.)

Also, it would be smart to introduce a separate dedicated datatype for 
type IDs, to not even tempt users to try comparing them with numeric 
literals. I'll eventually do a similar thing for stuff like RNGs and 
file IDs, which are numerical internally, but make no sense exposing to 
the user.


But I think I'm digressing here from the original topic.

Post a reply to this message