POV-Ray : Newsgroups : povray.pov4.discussion.general : Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) : Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) Server Time
19 Jul 2024 23:23:36 EDT (-0400)
  Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)  
From: Bald Eagle
Date: 28 Jun 2024 09:30:00
Message: <web.667eba654bc5dc75e21e5c0b25979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> > > I'm thinking a keyword modifier would be more flexible than a directive,
> > > for example:
> > >
> > >   #declare const GlobalVal = 12345;
> > >   #local const LocalVal = 54321;
>
> "modifier", yes.  +1.



>
> > Hmmm.   Yes, but maybe no?
> > Why not just have another separate type of declaration?
>
> the keyword modifier, more often than not I think, would be in close proximity
> to the variable where/when it's used.  an advantage.

In the absence of a concrete example, I'm wondering how the modifier would be
"more flexible", and what "close proximity to the variable where/when it's
used." means.

> > ...
> > So maybe #constant can ONLY be changed by specifically using another #constant
> > directive.
>
> if a variable's value can/will change "at runtime", #constant would simply be
> misleading.

Sort of.  I think the underlying idea is that it's not forever immutable, but
protected from unintentional and silent reassignment of it's value.

What about #protected?
It could be like function {}, where once declared, the parser throws an
(intelligible) error unless it's #undef'd before redeclaring.

The trick is balancing ease-of-coding with good coding practices, and new-user
friendly syntax so that we don't further steepen the learning curve.


> maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
> we can write better, "type safe" code.

Well YES.  Those sorts of things have long been wanted.
Camera location keyword/identifiers that would function like image_height, etc.
Identifier typing, especially for use in #read.
Differentiating things like vectors of different sizes, floats, etc.
View frustum coordinates or an internally defined 3D view frustum (maybe an
internal function that takes a length for the direction vector) that one can do
inside () tests with.

What really needs to be done is to draw a "map" of what we have coupled with
what we'd like to see.  That would function as a brainstorming vehicle, and a
to-do list.

Macros that people have written over the decades could be used as inspiration,
and I'm sure there are code libraries and things on GitHub, etc that have actual
c++ code or whatever language 4.x will be written in.


- BW


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.