POV-Ray : Newsgroups : povray.unofficial.patches : Initial povr branch keywords id_type() and id_types_match() : Re: Initial povr branch keywords id_type() and id_types_match() Server Time
27 Apr 2024 20:09:30 EDT (-0400)
  Re: Initial povr branch keywords id_type() and id_types_match()  
From: jr
Date: 28 May 2021 08:30:00
Message: <web.60b0e0d4827c6b0779819d986cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 3:48 AM, jr wrote:
> >> ...
> >> What I've not done for arrays vs mixed arrays as yet is look for a
> >> method 'like' that employed to break out a few of the object types like
> >> light sources(1). The object flags popped into my head on Tor Olav's
> >> question.
> >
> > I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> > and so perhaps a complementary function (eg) 'is_type_details()' which returns
> > an array mixed, where the various flags are used to distinguish one ("390")
> > object from another.
> >
>
> Yes, is_type_details(), a possibility, but it would be work creeping
> well past "easy."
>
> Aside: For the details which could be provided as strings of text as to
> type, my thought was this work would be pushed onto users - or some
> include file maintainer - in the form of a macro containing a big switch
> kicking out text or setting up an array with, say, response strings:
> "The is type passed to MagicMacro24 is a light_source."

I was about to suggest (almost) the opposite.  :-)

thinking that if one (you :-)) were to set up an enum, covering the basics
(float, bool, vector, macro, function, array, string, such[*]), then changing
(in the parser, between versions) ids could be "contained" in one mapping.  then
'is_type()', and later perhaps its companion func, would always provide
consistent "numbers".  and yes, some include file to turn the numbers back into
human speak would be v useful (will collaborate if thought helpful).

[*] off the top of my head.  in most ("95%") situations, I think, just knowing
it's "an array", say, without the "fall out" from using 'dimensions(foo)' when
it isn't, will suffice.


> ...
> > (and the (snipped) macro examples too, while safe to use, would not allow me to
> > catch (as in handle with own error message) the eventual "odd" value, I think)
>
> You understood. What I coded up there is checking on the cheap; POV-Ray
> does it and the result is an internal parser error. What I had in mind
> for what I think you want to do - using id_type() - is something like
> the attached test case. Yes/No?

thanks.  will look at code tonight/tomorrow.


regards, jr.


Post a reply to this message

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