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

Ron Parker <ron### [at] povrayorg> wrote:
:> Those member functions were pretty obviously inherited from "sphere".

: You're confusing objects with classes here.

  As I said in another article, there are lots and lots of
misunderstandings... :)

-- 
#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 <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> > Those member functions were pretty obviously inherited from "sphere".
> 
> You're confusing objects with classes here.

No, though I might have misunderstood Jan's example. I was assuming the 
complete lack of classes.
http://www.google.com/search?hl=en&q=prototype+based+object+oriented
http://www.cetus-links.org/oo_self.html

-- 
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

Jan Walzer <jan### [at] lzernet> wrote:
: 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...

  In fact, the povray SDL has currently very poor means of achieving good
modularity.
  You can't make modules (classes, structs, whatever) with public interfaces
and private attributes and implementations, you can't construct your own
abstract data types, you can't make objects (ie instances of these data
types) and so on. You can't even construct the most basic types of dynamic
data containers (eg. lists, trees and so on; and yes, I know about arrays,
but they are currently just too clumsy and inefficient as *dynamic* data
containers).

able to dynamically allocate them (and having references to these allocated
objects) would be an enormous step in versatility and modularity. Structures
and references cover most of the features needed for user-defined abstract
data types (although without interfaces they are still not very modular).

-- 
#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

Christopher James Huff <chr### [at] maccom> 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).

  I think that what he proposed was not embedding *povray* into a language
interpreter, but the other way around, ie. embedding a language interpreter
*into* povray. That is, just make a patch for another scripting language
support.

-- 
#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

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

>   I think that what he proposed was not embedding *povray* into a language
> interpreter, but the other way around, ie. embedding a language interpreter
> *into* povray. That is, just make a patch for another scripting language
> support.

He said "as well as be embedded into the POV SDL files".
Though I suppose you could do both...embed another language in the 
script, have another program go through, execute that code, replace it 
with POV code, and then pass the result on to POV-Ray.

-- 
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

In article <3c585ac5$1@news.povray.org>,
 "Tom Bates" <tho### [at] shawca> wrote:

> I still, however, have hoped to find a ray-tracer or graphics tool
> that has the OO features that I planned for my own rewrite.  I've
> even considered writing a parser that would take an OO syntax
> and generate standard POV code from it (once I have time for
> something like that).

Have you looked at my CSDL project? It will have a library that does 
just that.

-- 
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

Nice! What do I have to do to have a go at this stuff?

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

[code]

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

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message