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 18:25:10 EDT (-0400)
  Re: Initial povr branch keywords id_type() and id_types_match()  
From: William F Pokorny
Date: 28 May 2021 09:12:26
Message: <60b0ec3a$1@news.povray.org>
On 5/28/21 8:23 AM, jr wrote:
> 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).
> 

Suppose it could be done by running a script to build such a cross index 
as a check in hook or something.

There is today a basic enum to cross reference in the code that gets 
used when reporting messages and such. We're basically talking about 
some parallel ID enum to locked integer index I guess - which 
is_type_details() or similar could use... I'll think about it, but at 
the moment it all feels a bit clunky /ugly given the minor value to end 
users.

Bill P.


Post a reply to this message

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