Ken schrieb in Nachricht <36D62965.52AF9E50@pacbell.net>...
>Rudy Velthuis wrote:
>>
>> The problem with the POV script language is the fact that it was a very
>> simple language which has grown so radically, that more and more keywords
>> had to be introduced. This is because the language had a C-like syntax
and
>> didn't treat objects the OO way then. So there either has to be a radical
>> change to it, making it more like it should be: an object oriented
>> description language, or the wild growth is likely to continue.
>>
>> But I'm afraid we won't find many in the POV-Team to agree with us. And
we
>> might also upset old-time users, who often know the keywords by their
first
>> and last names.
>>

>  Since  I don't have the advantage of a programmers background the idea of
>assigning properties to a function as opposed to assigning a keyword is
>being lost on me. How can you do one without the other ?

I don't see an object as a function. An object is something which has
properties and can do something too (even if it is something silly like
falling sown or breaking).

Now POV is not ready for the doing yet, but IMHO every object has common
properties (texture, size, bounding box) and some specific ones: a sphere
has a radius and a center, a cone two "centers" and two radii, a cylinder
two "centers" but one radius, a box two opposite corners, etc. etc.

I would like to be able to access these properties, like in

#declare MyVect = sphere1.Center

or

#declare MyTexture = box1.Texture



>  I have always worked with the assumption that it is the job of the scene
>file writer, that would be us, to pass commands to the program. It needs
>this kind of input from the operater in order to process the information
>in a manner consistent with out needs. If you don't have specific terms
>(keywords) for assigning properties to a function you are passing to the
>program how will it know what you what it to do ?

I have a different concept of "keyword". In most scripts and programming
languages, keywords are a small set of control words, which define the
language (like "for", "while", "begin", "end", "switch", "object", "struct",
"int", etc.). All other words are just identifiers, which stand for a
string, a character, a numeric, an object/class, a structure etc.

There are many keywords in POV-Ray which are in fact just representations of
a numeric, like
prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
linear_sweep and conic_sweep. They are in fact just numerics which were
given a name. In my concept they would be constants or enumeration types,
which (jn this case) represent numbers. It would have done, if the creators
of POV had #declared these words as numerics and had made the PRISM_ITEM
property of a prism a numeric:

#declare linear_spline = 1
#declare quadratic_spline = 2
...


prism { linear_spline, 0, 1, etc...

would be equivalent to

prism { 1, 0, 1 etc...

Rememer, in POV-Ray we often use constants like that: the colors White or
Black, the finishes Shiny or Dull, etc. They are all examples of constants,
representing a POV structure. They are not keywords, although they influence
the output of the program of course. I would liked to have the same kind of
constant definitions for many values which are declared as keywords now. I
would like to get rid of these pseudo-keywords, without upsetting the
language. Of course there could/should be some kind of standard .inc, which
would automatically be defined, even if it were not physically present on
the (hard) disk (some kind of standard "run time" library). To most users it
wouldn't make a big difference, they wouldn't even notice it. Only the
semantics (the true meaning behind it) of the words would differ, not
necessarily their use or their output.

If I decide to #declare a linear_spline now, I'll get an error message. To
avoid these kind of conflicts, the POV creators defined rather extensive
keywords like "linear_spline". If there were only a few keywords, they could
be rather short, and the spline item could just as well be called "linear",
because it would only be valid inside the prism (like any property would
only be valid inside the object it is defined for), and it would be known it
were a spline item:

prism {
  Linear
  // etc.
}

 So you could use the same word in different objects with a slightly
different meaning. But they would not be keywords anymore, they would be
properties of this object (class). And if I would #declare a variable
Linear, it would not be confused with prism.Linear.

>  On the topic of changing the current scene file language I see the
>possibility of heavy opposition. There are the considerations of ease
>of learning a difficult program like this because of it's rich, easy to
>understand, object oriented language. You don't have to be a programmer
>to use Pov it if you are determined enough and it shows what people are
>willing to go through to see all of them pretty pictures that come out it.

I see this too. That's propably why we will have to cope with the old
POV-Ray script language much longer. Although it wouldn't be too hard to
make two different front-ends for the rendering machine. But if I understand
right, the POV-Team objects to this because of the possible danger of people
using (and making money with) their rendering back-end without the proper
front-end (script language parser) and without their consent.

> Another important point is the incredibly vast amount of resources
available
>that have been written as support for the program and all of these rely on
>the program language not changing. If you change the language you retire
the
>work of people from the last 8 years many of which have finally begun to
evolve
>into something useful.

Not really. You wouldn't change POV-Ray 3.1, so it would still be available.
Many programs written for DOS had to be rewritten for Windows. So why
couldn't Moray, sPatch etc. be rewritten for a newer language version? This
is not really very hard. E.g. converting Moray to Windows must have been
much harder.

> Additionaly there is the Pov Teams desire to maintain backward
compatibility
>with it's own incarnations. This kind of change not only has a clear and
>immediate impact on every user out there, it also makes many thousands of
>scene files obsolete and useless. The amount of blood, sweat, and tears,
that
>went into the making to those scene files would make the person who changed
>the program into something considerably less than a saint or friend of the
>people.

These scene files would still render with the current POV-Ray.

And the changes wouldn't be too drastic. POV-Ray has changed in the mean
time too (the treatment of commas, the semicolons in single line #declares,
the demission of halo come into my mind). It would be easy to write a little
conversion utility to translate 3.x source to the new source. Most of the
source wouldn't even have to change. Propably only the syntax would have to
be stricter, perhaps even that would be unnecessary (I know how many would
object to that alone).

BTW, most of my views presented here are not fully though out, but I think
one could get rid of many pseudo-keywords without turning old scenes
invalid. One would perhaps only have to include one or a few new standard
.inc files, doing the #declaration of the pseudos as constants.

But I know, this is propably a very impopular view altogether, so I do not
expect any changes along these or similar lines. It would be nice though, if
we could at least *read* some of the properties of some objects
(camera.position or light_source.color).

 --
Rudy Velthuis

Post a reply to this message