On 3/20/23 23:31, Kenneth wrote:
> Well, on 2nd thought, I do see at least one special-case string use: To try to
> easily determine if a particular #include file is actually present in a scene.
I'm having a hard time seeing a good reason for the capability. If you
are trying to do something like swap in simple stand in for a complex
model while developing a scene, it seems like you should just set that
up on a declared true false variable ahead of time.
Maybe you'd want to automatically use a simple stand end until the
include of the complex model is created. Well then you could use
file_exists() and the complex model will be included as soon as it exist
somewhere POV-Ray can find it.
A failing include stops parsing.
Folks often include far more than they need (stnd.inc ?) for any given
scene. While that slows down parsing, it usually isn't a fatal mistake.
Unfortunate undefs or re-declares to the same IDs do happen, and that is
the one place where a user might want to throw an error if, say, he
knows POV-Ray's color.inc has the potential to undo his flavor or Red.
But, then maybe, MyBetterThanPOVRayRed is a better name... :-)
Not arguing you couldn't use the functionality, it's just hard for me to
see the return on investment.
Aside: Even checking the name there is a search order for the file too
and, if there are multiple files called color.inc available, the next
feature request will be something about knowing which actual color.inc
I'm thinking, jr, about a keyword_exists() kind of feature.
Aside: I'm digging around more on the - since 2015 - ifdef(), ifndef()
v3.71/v3.8/v4.0 behavior; I noticed when keywords are passed, Christoph
made updates to some releases to kick out a warning:
Trying to test whether a reserved keyword is defined.
Test result may not be what you expect.
(or a similar message depending on releases)
I take it as evidence he was playing with looking at more than IDs - or
perhaps he realized there was an unintended an unintended behavior he
needed to back out (a part of it he did for v3.8). For povr I'll likely
leave the message in place on restoring v3.7 and prior behavior; Users
can get different results depending on what release code they run on
Yep, I need to look at how he made the inbuilt keyword determination for
the message - there are hidden reserved words too which are not visible
SDL 'keywords' / reserved words. Msg method might offer a way to an
Post a reply to this message