The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Attached to Project: POV-Ray
Opened by Mike H - 2010-06-09
Last edited by William F Pokorny - 2017-01-21
Opened by Mike H - 2010-06-09
Last edited by William F Pokorny - 2017-01-21
FS#129 - Hash arrays
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
How do you loop over such arrays ?
POV-SDL is not php, I do not feel the need of a foreach()... nor a ksort().
Nice seems a bit frivolous here.
It's easier to remember names than index numbers. If you have a group of related items (stored objects, variables, macros, etc.) then you can use the same naming scheme throughout. And, if you have more than one array you don't have to worry about the arrays being equal in length, or if they have had items added or removed to/from them: the index will always remain the same.
POV-Ray is not a scripting language in the sense of the ones that offer the feature you are talking about. You can declare special indices in advance, then they are easier to remember.
Er, what? That sounds bogus to me. "POV-Ray is not a thing that has that feature, therefore it is not a thing that has that feature." That is the point of "Feature Requests" isn't it, or am I retarded? Don't the POV-Ray docs themselves brag about how you're able to write a complete ray-tracer within POV-Ray using only SDL? And plenty of non-"scripting" languages support hash (associative) arrays. Or do C++ and C# not count?
what about simply declaring your "string" index with classical #declare.
Instead of
You can already have
#declare Mike = 3;
...
Associative array in C++ are called maps, not arrays.
(unless you want only an #enum for povray ?
#enum { Mike, Thorsten, Jerome } ???
)
What if:
Isn't going to work.
I can lead the horse to water, but I cannot make it drink.
Good practices would be for the last code to have instead:
(and we might be missing a few semi-colons)
Now tracked on github as issue #198. Perhaps the new ‘dictonary’ feature completely satisfies the request? If so, please close out on github.