"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48d874f9$1@news.povray.org...
> I think we need to move forward on
> stuff like this without the fear of being bound to the past, while at
> the same time keeping in mind that one of the impediments to upgrading
> any software is if a user's old files don't work (properly). Hence we
> need to balance things and provide backwards compatibility where possible.

cool .... we're on the same page then.

> If (as it appears to be the case) the SDL as it stands doesn't provide
> a clean way of deprecating existing constructs while still permitting
> their use, then we need to enhance the SDL. I'm inclined to add such a
> means. For example:
>
>  #declare I_Glass4=
>    deprecated once "... some message goes here ..."
>    interior {
>      ior 1.5
>      fade_distance 2.0
>      fade_power 1001
>    }

> if we did it this way, for example, the #declared item is known by the
> parser to be deprecated: this generates no warning during the parse of
> the #declare itself (or even if the #declare is used in another
> #declare), but if it is used in an actual object, the message
> associated with it is displayed (if the 'once' keyword is present,
> it's only displayed once per parse, otherwise it's displayed each time
> it's used in an object).

How big of a deal to do this? Giving the parser the means to do this could 
be useful for furture change issues as well right? This issue (I_Glass) 
isn't the first time and I'm sure it wouldn't be the last, so I kind of like 
this idea at first glance.

> I'm not saying it has to be done this way; it's just one thing that
> comes to mind. It would require the parser to track the deprecated
> status of each #declared item (passing up the state if a new declare
> inherits a deprecated declare, and so forth), which isn't as clean as
> I'd like it to be. The other option is to display the warning anytime
> the declare is used (even if in another declare, which means we have
> to ensure we don't use such declares as part of something else in the
> same standard include file as this would trigger the warning even if
> the end-user didn't use the #declared item).
>
> -- Chris

I've pseudo coded an idea but haven't had the time to see if it might lead 
anywhere. Basically the idea would use a function to return the state of a 
toggle so we could conditionally provide a warning, but your suggestion has 
me thinking that my idea is more of a patch than a solution.

Jim

Post a reply to this message