Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Rather than have an entire CLR, you could have the program structured to 
>> have C libraries (or C++ classes, I suppose), and clearly document how 
>> they're used. Then the SDL parser would invoke constructors building the 
>> classes, then invoke the "render" method.
> 
>   That would mean that 1% of the povray community could benefit from that,

The point of doing it that way would primarily be to allow those writing 
the SDL to use one of the many languages that already exist to avoid 
having to reimplement anything in the SDL except the ray-tracing. Need 
formatted input/output? Need to read CSV files? Want to store objects or 
libraries in a database, or in google-file-system? Want to send a 
message over a socket each time a frame finishes? If you use an existing 
language that can interface to C, like Java, Tcl, Python, Lisp, etc etc 
etc, you get all that sort of stuff "for free". Of course, munging your 
SDL syntax to match the language you pick can be a bit problematic, but 
it's not *that* hard to solve, especially if you pick an appropriate 
"base" langauge.

Hope that clarifies.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message