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 
POV-Ray included.

---

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:

Parse 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 
testing keywords.

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 
iskeyword().

Bill P.

Post a reply to this message