POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion : Re: Reviving some pov4 discussion Server Time
13 May 2024 09:57:13 EDT (-0400)
  Re: Reviving some pov4 discussion  
From: Le Forgeron
Date: 12 Dec 2015 03:32:02
Message: <566bdb82$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 12/12/2015 00:32, clipka a écrit :
> Am 11.12.2015 um 22:37 schrieb Le_Forgeron:
> 
>> If I was crazy, I would use C++ and a compiler as the parser,
>> filling a scene object with other objects...
> 
>> Povray::Torus obj1(1,0.1); // texturing can be a post constructor
>> operation Povray::Cone obj2( Povray::3DVector(0,0,0), 1,
>> Povray::3DVector(), 2);
> 
> Still unnecessarily complex, as compared to (e.g.)
> 
> cone { <0,0,0>, <0,1,0>, 2 }
> 

Please notice, I wrote "If I was crazy".

of course C++11/14/17 could be abused with initialiser list in
constructor for:

scene += Cone( {0,0,0},{0,1,0}, 2);

that is just a matter of supported syntax for any language, I took
C++, but it would be the same with any other.
> 
> One of the key properties of a POV-Ray scene, which make the 
> requirements for the future SDL so unique, is that it may contain
> (A) descriptions of complex algorithms as well as (B) descriptions
> of hierarchical data, mixed arbitrarily.

[cutting the very good list of expectations]

Just beware of the NIH syndrome.
As well as over-generalisation (e.g. let make a super-generic system
to handle unthinkable evolutions), that's how you finish with heavy
XML inside SQL database, with mandatory manual joint using regular
expression applied on the single table of 2 or 3 columns, instead of
unfolding the whole data scheme across multiple dedicated tables (but
yes, a data scheme does not evolves to handle any extension, and due
to lack of initial strict requirements, you have a meta-engine instead
of a dedicated engine... so customers can customize it as they want...
well, there is no customer which are ready to pay for a meta-engine
and then pay again the customisation... excepted in the ERP/SAP
business model (or is it a mafia ?)).

Despite the C-like origin of SDL (or pascal... or whatever was fancy
in the 80's ), Povray is very object oriented.

Do we want to look at it like an interpreted or a compiled language,
it might be irrelevant for the speed, but in the approach provided to
the new users.
Do we want to write our own parser, or can it be left to an existing one
 ?

If it was one of boost library, would it still be povray ?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlZr24EACgkQhKAm8mTpkW3eHgQAntLCC+Elu2b0LKan1I1Azonk
pPBuGjJLnWqJYwWBdtuPRzid7jA/sATpfVWrQ5MOZCFszDWU3t4Ao1HjhT73i2kP
bKFPs/P+bYWOd3mhnpgYDScOSs0aTL9UFZjY1jsr0La8aQf54ltl5iuyPbpbMm57
b+z5S/wR6ogjdEgu7mM=
=0HOR
-----END PGP SIGNATURE-----


Post a reply to this message

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