Hmm, I just couldn't resist converting this to CSDL (or at least, 
something that resembles what CSDL eventually will be):


object POV = load("povray.csdl");

object MySphere = POV.Sphere {center = <0,0,0>; radius = 5;};

object MyMaterial = POV.Material;
MyMaterial.texture.pigment.color = < 1, 1, 1>;

MySphere.SetCenter(<5,2,5>);
MySphere.SetMaterial(MyMaterial);

MyMaterial.texture.finish.ambient = 0;

object MyBox = POV.Box {
    material = MyMaterial {
        texture.finish {
            reflection = 0.7;
            ambient = 0.0;
            diffuse = 0.2
        };
    };
};
MyBox.SetCorners(<-1,-2,-3>,<1,2,3>);
MyBox.Translate(<-5,0,8>);


POV.AddShape(MyBox)
POV.AddShape(MySphere)
POV.AddShape(
    object POV.LightSource {location = y*20; color = < 1, 1, 1>;});

POV.camera {look_at = 0; location = y*5 + z*-10;};

POV.render()

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: I assume you're referring to the claim that POV SDL is OO here.  The POV
: source, though written mostly in C, could be said to have both inheritance
: and dynamic binding.

  Yes, I was talking about the POV SDL.
  I know that the povray source code, even though written in C, uses pretty
much object-oriented features (of course it's a bit clumsy to do this in C,
as it has no direct support, but possible).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

>   Modular languages (eg. Modula 2) can have classes, member variables,
> member functions, public and private parts, etc, but if they don't support
> inheritance and dynamic binding, they are not OO.

But Jan's example does use inheritance (the setCenter() and 
setMaterial() methods) and wasn't complex enough to show dynamic 
binding...


>   OO just happens to have been the hype the last 10-20 years and people call
> almost anything "object-oriented". There was a joke in some OO forums that
> if you want to sell your cat, you shouldn't praise how nice and clean etc
> the cat is, but you should say that the cat is object-oriented.

I've got some free kittens, they all demonstrate inheritance pretty 
obviously and are very dynamic...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: But Jan's example does use inheritance (the setCenter() and 
: setMaterial() methods)

  Uh? Calling a member function is not inheritance.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
: Christopher James Huff <chr### [at] maccom> wrote:
: : But Jan's example does use inheritance (the setCenter() and 
: : setMaterial() methods)

:   Uh? Calling a member function is not inheritance.

  I think it would come closer to OO if you could do something like:

class MySphere: specializes sphere
{
  virtual setCenter(Coords)
  {
    do_something_with(Coords);
  }
}

  Then you could have functions (or macros) which take 'sphere' type objects
and to which you could give wither true spheres or your MySphere and if
this function calls 'setCenter', the correct implementation will be called.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

My Idea was, to have a constructor that resembles the "old" SDL ...
So with some minor wrappings, you could use old code and on the other
hand, can later modify it...

So pure Java was not the solution
(Except you put this constructor in as a String (Hey, thats the idea ...
I think, I can specify such a thing ... can I ?))

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

In article <586### [at] 3-enet>, Daniel Matthews <dan### [at] 3-enet> 
wrote:

> There is nothing to stop the embedding of an existing OO language ( like 
> Ruby ) into the POV GUI with POV libraries or bindings to some form of POV 
> API. This meta scripting language could drive the GUI and external 
> utilities as well as be embedded into the POV SDL files.

Well, there is one thing: licensing. The current POV license is pretty 
restrictive (though for very good reasons).
Of course, you could just write a library in that other language that 
generates a scene and calls POV. That should be perfectly legal, as long 
as you don't hide the fact that your program/library is a separate piece 
of software using POV-Ray. That's what I am doing for the CSDL POV-Ray 
scene library, and I think Moray does it.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

The first sentence was more a rethoric one ...

Reality is: _I_ (read that this means Me, and only Me) don't care, if SDL
resembles OO by the definition, or not... Maybe it would be enough, to stay
modular...

I just typed, what _I_ would like the SDL to be...
I've no complete concept of this yet, how to handle different types and
properties ...
Maybe it makes sense, to implement inheritance into this concept ...

BTW: wasn't modula2 this pascal-like thingie ? ... (I think it was the other
way around)

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

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

>   Uh? Calling a member function is not inheritance.

Those member functions were pretty obviously inherited from "sphere".

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 30 Jan 2002 17:35:15 -0500, Christopher James Huff wrote:
> In article <3c586ea0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
>>   Uh? Calling a member function is not inheritance.
> 
> Those member functions were pretty obviously inherited from "sphere".

You're confusing objects with classes here.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message