On 1/26/22 11:25, jr wrote:
>> Would using f_odd() in this way be useful or not? It's all I've got for
>> options at the moment.
 >>
> unsure.  a function return to test against would not be very different from
> comparing string ids, and it sounds like it would work.  otoh, it feels like,
> um, a crutch.

I've been thinking about this.

Instead of using f_odd() to return additional patch/branch information, 
I think it should instead return always a value f_odd() cannot. For 
example, 99.0(a).

The 99 indicates the code contains a patch or is a significant branch of 
its own. Further, that two additional parse time functions exist in:

patch_str(<n>) and patch_val(<n>)

With this approach we use f_odd() as a hook into all versions of POV-Ray 
back through v3.5(c) to indicate the two patch_* keywords exist.

What each branch/patch provider does with those is up to them both to 
implement and document to their users.

Allowing any number of strings and values would allow documenting 
particular functionality and the version of that functionality -> 
"amplify" 0.003.

Is this a better approach(b) than f_odd alone?

It's gets us away from any dependency POV-Ray's official development.


Aside: I had the thought too for a patch_keyword("sky_sphere"). Which 
might return say "unchanged". Or "emission sub keyword is now amplify" 
or "removed" or "new" or "substantially updated see povr documentation" 
or... I'm thinking more about code which self documents to some minimal 
degree.


Bill P.

(a) - It happens the return of f_odd (and its twin f_cushion) are 
clamped to a -10 to 10 range.

(b) - With official POV-Ray there's been significant effort to maintain 
near infinite backward capability so old scenes and tooling writing 
POV-Ray SDL continue to work.

A place and value for this approach, but it doesn't come free. The 
reality is a fair bit of the backward capability is bent if not broken 
to what is documented. To the degree it's tested due old scene and 
include files, it's probably workable.

It's much harder to write significant patches if you have to worry 
yourself about maintaining infinite backward capability. My povr branch 
supports only v3.8+. So as a patch_* return pair I might also have:

"Minimum POV-Ray version" 3.8

If v4.0 development resumes, there will be a point where I won't be able 
to retrofit some v4.0 change / feature to povr and I'd then need maybe:

"The povr branch is aligned with POV-Ray version" 3.8

(c) - I'm only aware of patched versions back through v3.6.

Post a reply to this message