In article <399ff446@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> : Why would more OO features in the scene language improve its usability?
>
>   What I am personally still missing from povray are dynamically allocated
> objects (where, the objects in povray are indeed dynamically allocated, but
> their syntax makes them quite static) and references or pointers to handle
> them.
>   That would allow making, for example, linked lists, trees and so on.
>
>   If those were implemented in an object-oriented way, it would be a plus.
> Making them in a C way would just cause a lot of spaghetti code.

Hmm, you seriously want to call the C++ STL anything else but "spaghetti
code"?  ;-)

Did you consider more abstract Basic-like (READ: in the spirit of ease of
use and learn typical for the average Basic, NOT the syntax style of Basic)
syntax for it?  POV-Ray already has a few hundred keywords, would the ten or
so for a simple built-in implementation really matter compared to the two or
so needed for a C++/Java style implementation allowing references (no
pointers, pleeeeeeeeeeeease!)?

>   And object orientedness would help making better scripts. Perhaps most
> users will not get any advantage of it, but most include file makers
> certainly could.

Since when does object orientedness improve programming?  How many books,
lectures, labs and practice did you need to master the basics of C++ (not to
mention the basics of object oriented design) compared to the basics of POV?
How many "users" of POV-Ray would really benefit and have the background to
use it?

>   Just think about the possibilities Include files using common abstract
> base classes could be used more or less seamlessly together. Clear
> interfaces will make them easy to use and maintain, and information hiding
> will help avoiding all namespace trashing problems (there's nothing more
> annoying than two include files using identifiers with same names).

For whom?  Programmers with a Ph.D. or the average user with perhaps one or
two years of (hobby) programming experience?

namespaces are a problem, but they can be overcome by simple organisational
manners, without the need for a language extension.  Namespaces are merely a
hack to allow programmers not to talk to each other and follow naming
conventions that could be set by a majority vote and central name
registration system!

> : Would it be easier to learn?
>
>   It doesn't matter. You don't have to learn it if you don't want it.

Great argument!  Who cares if someone can read a POV scene and learn from
it, why should there be new novice users of POV-Ray?

Please read [1], maybe then you understand and leave your tower <sigh>

> : Would it be fast to parse?
>
>   Would it be slower? Does it matter?

Yes (answering your second question).

> :  Would it allow
> : porting C/C++/Java programs to POV-script?
>
>   Why anyone would want to do this? They do different things.

See my note to Chris Huff :-)

> : In short : What are the _practical_ benefits for the scene description, the
> : primary purpose of the POV scene description language?
>
>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
engine!  There are features that have more relative value compared to their
cost while others have a lower relative value compared to their (possibly
very high) cost. Note the "relative".


       Thorsten


[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message