hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/14/22 10:57, jr wrote:
> > ...
> > I (still) think that the .inc would be a good place to store other
> > 'povr'-specific stuff too, like the ids.
> >
>
> Here, I wonder if perhaps the scale of change in the povr branch is
> being seen as less extensive than it in fact is. ...
> In other words, in just supporting multiple forks over time,
> it could grow substantially in size. I see no reason this file cannot be
> shared - at least to some degree - across forks.

yes there is much divergence, and I had not thought "forward", ie after a number
of subsequent releases, so scratch the thought.  (I focus perhaps too much on
"everything in one place", anyway)


> > from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
> > hoped for a 'version.inc' which would work regardless, for any version and/or
> > fork of POV-Ray.
>
> I'll try to reduce / rework the mentions of povr.
>
> The current forkversionhook.inc does work for any POV-Ray version - at
> least when I've tested it.  ...
> I'll add a commented #debug where I
> had an empty else block indicating something which could be printed when
> the fork hook is not found. It's commented because I don't want to
> default to always printing something on inclusion of
> forkversionhook.inc. Regular include use will be to make the
> 'Have_f_odd_fork_hook()' macro available to scene code and nothing more.

works as in parses, but (empty else branch) no feedback when it isn't povr.  I
think that I'd hoped for a situation where POV-Ray proper and (eventually) all
forks supply a version.inc which tells, basically, whether or not "official";
forks, and POV-Ray, are then free to add constants and or macros to probe
further.


> > Have_f_odd_fork_hook()
> > lastly, the constant + macro names are, um, a little verbose?:-)
> ...
> Beyond that I'll take you to mean, perhaps, something like the following:
>
> forkversionhook.inc -->  forkhooks.inc ?
>
> Have_f_odd_fork_hook() --> HaveForkConstants() ?

:-)  'forkversion.inc', actually.  it's the "hook" that's .. surplus in my view.
 I don't mind the underscores, think they aid readability.


> ...I'm less a fan of shortening the constant pairs, but...
>
> fork_str(n) --> frkstr(n) ?
> fork_val(n) --> frkval(n) ?
>
> Better?

ouch!  personally (if it mattered) 'fork_{str,val}' is fine, though I'd probably
write 'fork_{key,val}'.


regards, jr.

Post a reply to this message