In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
> Thorsten Froehlich wrote:
> But POVRay 
> files are rather small. Parsing speed does not matter that much.
> 
Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to 
parse than the actually rendering. The very idea that size, complexity 
and speed in that step is irrelevant is.... incomprehensible..

> Now for the 4.0 rewrite: What will it be like? I just googled a bit, but 
> I couldn't find anything about it. How do you know that similar 
> limitations like the ones described won't appear again? Is there any 
> information about it available?
> 
First off... Thorsten Froehlich is on the development team for this 
program, so one would think he would have a clue what the flaws are and 
why your idea is purely nuts. Yeah, there is one application of XML I can 
think of that provides for programming, but it does so by borrowing the 
<script></script> tags from HTML and using real languages to do the work. 
The rest of it is just parsing of user readable information that defines 
simple behaviours and settings for inbuilt functions, not complex 
objects. It also uses name spaces to keep things straight, but doesn't 
allow directly talking between things in different name spaces. Why? 
Because the same 'include' might be used in several different XML 
plugins. Each of them could use the same function names, the same names 
for objects, etc. and keeping all of them straight, even with namespaces, 
is easier is they never directly interface in any way. The interfaces 
that are supported involve using a unique UID for each one, to make sure 
they don't interfere. With POV-Ray, even with separate spaces, these 
things have to interoperate and coexist. That has to be handled 'by the 
application'.

What form the data takes in the source file has nothing to do with the 
function, only the time wasted a) coding it and b) parsing it. Making it 
intentionally more complex doesn't fix the problem, which is not in the 
file, but in the way the application handles the information. You could 
use bloody Sanskrit on punch cards, Tolkein's elven language transmitted 
by brain waves or even your XML idea and it wouldn't alter the fact that 
the problem is in the limitation of how the data is handled 'in the 
program', not how it is represented in the SDL itself.

Argh.. Its like arguing with someone that insists printing Bible quotes 
on toilet paper would be sacrilegious, it has to be exactly such and such 
font, this specific size, the paper made from only the finest rose wood 
pulp, blah, blah, blah. Only the real argument is if the Reader's Digest 
Condensed version leaving out all the verse names and insisting on 
calling Moses, "the bearded guys with a stick" was the best way to get 
the story across. lol Which is more important, that the program supposed 
the feature everyone admits is missing, or that it was painted in the 
most recent style? BTW, I equate XML with pointillism. Complicated, 
insanely anal and totally pointless if there is a more efficient method 
to solve the problem. Maybe, given 50-60 years it will actually look 
'useful' for some programming applications, much the way pointillism more 
or less accidentally hit on the idea for digital video, years before it 
was remotely practical for anyone without a lot of patience and several 
loose screws to use the idea. However, I strongly suspect it won't. lol

And for the 99,999th time on these news groups. Version 4.0 features are 
not yet even technically 'in development' yet, which makes it a bit hard 
to discuss what or how anything will be implemented in it.... Nor has the 
team expressed a desire to discuss it and have 500 people telling them 
not what will improve the ideas, but how they are doing it all totally 
wrong.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message