Hello,

 just an idea: imagine, that POV language is object-oriented,
 so for example sphere can be defined something like:

 Sph1=sphere;
 Sph1 < rad(1) < cen(<0, 0, 0>;

 CSG:

 Union1=union < add(Sph1) < add(Sph2);

 Global settings:

 global_settings < radiosity(on) <  background (rgb .5);

 '<' means 'send messasge to object'.

 Inheritance can be great for making complex custom object,
 with they own functionality,
 for example beam object, which is able to place itself
 between some two points as abstract class and his descendants
 with particular shapes, then I can use all beams in place
 where I need beams a there is no necessity to make some
 #switches.

 Any ideas?

Regards

Disnel

Post a reply to this message

Vaclav Cermak wrote:
> 
> Hello,
> 
>  just an idea: imagine, that POV language is object-oriented,

This is probably one of the most discussed subject ever in
these groups.  I'll suggest you to take a look at the numerous
past discussions about the idea of making POV-Ray's language
more object-oriented.

Fabien.

Post a reply to this message

Fabien already answered you.
  I would like to add that although object orientedness would be wonderful
from the point of view of a hardcore programmer (like myself), it would be
of little use to the average user who knows little or nothing about
programming (who are still fighting on understanding how #while-loops and
#macros work...).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Vaclav Cermak wrote:
> 
>  just an idea: imagine, that POV language is object-oriented,
>  so for example sphere can be defined something like:

Will it render faster?

Will it parse faster?

If not, forget it.

Regards,
John

Post a reply to this message

In article <39747AD8.E2567B43@itam.cas.cz>, Vaclav Cermak 
<dis### [at] itamcascz> wrote:

>  just an idea: imagine, that POV language is object-oriented,
>  so for example sphere can be defined something like:
...
>  Any ideas?

This has been discussed many times, you might want to look at those 
discussions. There was one big one which started out in povray.general.

The biggest problem with your syntax is that it would require a complete 
redesign of the POV language, and everyone would have to re-learn it. 
This isn't necessary, object-oriented features could be added to the 
existing language, and still support old scenes and people writing in 
the older style. For one thing, the dot operator is already used to 
access the components of vectors and colors, it makes sense to use it to 
access member variables and macros. Much more sense than to use the 
"less than" operator.
A form of inheritance could be done by having every copy of an object 
get independant copies of its parent's members.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <3975A3CF.43674EB9@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> Will it render faster?

Of course not, it is part of the language.


> Will it parse faster?

Well, the complete rewrite that this particular syntax would require 
could easily lead to a much faster parser. Just don't forget about the 
fact that a rewrite is already planned. :-)


> If not, forget it.

You seem to have forgotten about ease of use. On the one side, speed is 
irrelevant if only a few people can or will use it. On the other, many 
things would be much easier/more efficient with some object-oriented 
features. It is possible to add these features without forcing everyone 
to re-learn the language.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

An idea:

Have a constructor for each object that will initialize it with the
necessary properties.

sphere ballA(<0,1,0>,1);

The object could contain other objects for texturing and have member
functions for transformations.

ballA.finish.specular = 1;
ballA.translate(<0,0,10>);

The destructor could make the object go out of scope so that other
objects could reuse the destructed object's name.

~ballA();

It looks like a total redesign.  %-\

Brendan

Post a reply to this message

On Tue, 18 Jul 2000 17:42:16 +0200, Vaclav Cermak wrote:

> just an idea: imagine, that POV language is object-oriented,
> so for example sphere can be defined something like:

[...]

> Any ideas?

The povray scene language is good, because it can be used by professionals as
well as amateurs. Object-orienting things will probably need to break
backward compatability somewhere, and only a handfull of users will actually
understand the benefits of the new OO language.

However; No one has said that you, me, anyone can't write a Pov++ language
which can be "compiled" to simple .pov files. The output pov-source will
probably look horrible, but what the heck.. :-)


 /j

Post a reply to this message

> This has been discussed many times, you might want to look at those
> discussions. There was one big one which started out in povray.general.

I readed something from this very, very long thread.
I remember some ideas from it:

1) Possibility to give a name to object and then use dot operator, like:

sphere {
  name "Sphere1"
  ...
}

....

Sphere1.texture= ....

  Persistent animations can be done with it, for example:

Sphere1.persistent=yes

  and in next frame:

Sphere1.translate(<somewhere>}

  or

Sphere1.delete()

  It has backwards compatibility, my first idea not.....


2) No one talked about virtual methods, although its big advantage, I
think.

3) XLM is good idea for sharing POV scene with modellers, converters and
   so on, but I think that is very unfortunate for hand-coding.

4) Interesting idea of breaking POV into two parts: parser and renderer,
   then can be simply parser for actual POV language, parser for XML...
   If we enlarge this concet, an XML emitor can be connected to parser
   instead of renderer, for example.

> A form of inheritance could be done by having every copy of an object 
> get independant copies of its parent's members

This is true when you don't allow changing objects after they have been 
parsed, but I think, that can be one great advantage, mainly in
persistent animations.

Regards

Disnel

Post a reply to this message

John VanSickle <van### [at] erolscom> wrote:
: Will it parse faster?

: If not, forget it.

  Oh, so then we should remove #while-loops, #macros and even #defines. They
only slow parsing, don't they?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message