hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/22/21 8:02 PM, Bald Eagle wrote:
> >> Perhaps we need an istype() function like jr suggested.
> > It would be great, especially since then we could type thing in CSV files as
> > they're being read in, and would need foreknowledge of the file structure.
> > ...
> Somewhere in this thread jr had a feeling istype() wouldn't be too
> difficult to implement. I didn't want to think about this having already
> quite a mess in my head, but my head has.

back when I used to be real good at giving people headaches.  ;-)


> I think something like idtypesmatch() might be relatively simple(1).
> You'd set an id to a reference thing. Then compare other IDs against
> that reference by internal type. The function would return 0 or 1.
> Useful enough?

sounds good, having a design that returns a bool is v elegant.  and should work
well, eg, when writing a macro for "public consumption" since I could provide
what (argument type) I look for and compare it to the parameter supplied.

(there's lots I'm not clear on, say, 'array [2][2][2]' would compare equal to
any size 3D array of same float/vect/whatever, and such, but like the
design/idea)


> Once into something like istype(), we at a minimum need to make all the
> types of interest accessible by name in the SDL. Internally there are
> type classes - 'someKindaVector' and so on which would likely be useful
> to have defined too. The implementation complexity rapidly increases, if
> you want to set up or store types for later work in a parser aware way,
> define types priori, ...
>
> Bill P.
>
> (1) - Less controlled variations could store values of types via say
> typevalueof() in float capable 'storage-types' for later float to float
> compares. Note. The type enums within the parser are not constant, but
> change as the parser keywords change. Meaning one would always have to
> run typevalueof() against reference 'things' to get the POV-Ray
> version's baseline type values against which to compare other things.

had not envisaged anything as sophisticated.  thought if 'istype()' returned an
integer value corresponding to type[*] of "foo", and the documentation has a
(lengthy) table with suggestive but not used symbolic names (derived from the
underlying enum) and their numeric values.  anyway, past.  :-)

[*] coded presumably to keep the actual number of "types" down.


regards, jr.

Post a reply to this message