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
11 Oct 2024 16:54:59 EDT (-0400)
  Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)  
From: jr
Date: 29 Jun 2024 01:00:00
Message: <web.667f94264bc5dc75c7a7971d6cde94f1@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > > [Cousin Ricky]
> > > > 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.
>
> > > 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.

the "close proximity" thing is shown in CR's suggestion, note the 'const'
immediately in front of the variable in question.

"flexible", for instance, a (say) '#constant' directive alone and the macro
definition would still offer no "visual clues" wrt the arguments also could not
be used in expressions either.

(and remember, I'm no "language designer" either :-))


> > 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.

see reply to WFP.


> 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. ...
> 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.

agree, a in-one-place collection of things needing doing, plus "feature
requests", is very much needed.


regards, jr.


Post a reply to this message

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