On 2/26/22 05:37, Bruno Cabasson wrote:
> Thanks for the update! But what about Christoph? 

He's not been recently active is all I know.

> 
...
> 
> HOWEVER, and despite that situation, the dictionary container gave me the idea
> that it could be possible to imagine using them for classes, instances and some
> fundamental Object Oriented features. I think that if it happens to be feasible
> and if it happens to be usable without syntactic over-complexity or
> non-readabiliy, I could be open the object-orientedness for POV-Sdl. It could
> help for complex scenes, animation, whatever an object-oriented language is
> handy (or necessary).
> 
> So, I had it a try.
> 
> AND I reached something quite fine (though it is just a Proof Of Concept until
> now)...
> I could implement :
>      classes,
>      instances,
>      properties,
>      methods,
>      inheritance,
>      overloading for contructors and methods,
>      named parameters,
>      new(), super(), instanceof() operators,
>      type-ckecking,
>      templates,
>      and a few other minor OO features.
> 
> Do you think it could be interesting for the POV community ? For fun, I named it
> PROOF (Pov Ray Object Oriented Features).

I like the acronym. :-)

Certainly of interest, especially, as a way to flesh out ideas for a 
potential v4.0 SDL concepts/syntax.

Ingo and jr in particular have been pushing ideas using the dictionary 
feature of v3.8/v4.0 over the pass 3-4 years. I also picked up TOK's 
newer dictionary based array statistics code as a stand alone 
arraystatistics.inc in my povr fork.

---
Practically, you might come up against issues.

Being based atop current parsers, performance a concern. As 'proof' of 
concept code this will matter less.

To be sure you are aware. In 2018 and early 2019 Christoph was 
significantly changing the internals of the - then v3.8 - parser. At 
that point all development stalled for roughly 2 years starting in early 
2019 until Christoph resumed working on POV-Ray for some months in 2021. 


On his return in 2021 he broke development into a v3.8 release path 
where he backed out code he considered to be too new for a near term 
v3.8 release. This included backing up the parser code to an earlier 
v3.8 state. The newest parser code still exists in the master branch 
which is now more or less aimed at v4.0. Both parser versions are - 
today - SDL / language feature equivalent (excepting a few fringe cases).

However, last I knew, there were remaining parser issues in both 
implementations. IIRC there is at least one dictionary issue still in 
v3.8 fixed in v4.0.

My personal povr branch is based on the newer (v4.0) version of the 
parser code which 'was' in v3.8 when I forked off the povr work. I 
'believe' all the v4.0 parser 'bugs' of which I am aware have been 
addressed in the povr branch. In aspects the parser in povr has evolved 
into another 'internal' parser implementation - though again the SDL 
feature set is substantially v3.8/v4.0 equivalent today.

New v4.0 SDL concepts/syntax and radical changes to the parser are not a 
presently a focus for me as I play with POV-Ray. I end up in the parser 
code when something needs to be understood / fixed - or it's otherwise 
in my way.

---
Aside: Our existing scene description language (SDL) - as a language - 
supports certain object oriented 'concepts' today. Our implementation 
doesn't back them in a consistent way and so people tend to avoid the 
approach. The situation due internal coding choices and, often as not, 
bugs.

For example, something like the following is supposed to work in POV-Ray 
today with fog, but it doesn't(1). The internal structure and code is 
all there - but for bugs.

(1) - You can write similar parser clean code, but in the rendering 
details it very often isn't working.

Using the povr fog example (povr's fog and related keywords somewhat 
different) and today's SDL:

//...
#declare Fog01 = fog {
     type 1
     distance 9.5
     color Grey70
}
#declare Fog01_wTurb = fog {
     Fog01
     it_scale <1.6,0.16,1.6>
     it_depth 2.1
     it_octaves 5
     it_omega 0.35
     it_lambda 1.25
}
#declare Fog01_neg_it_depth = fog {
     Fog01_wTurb
     it_depth -2.1
}
#declare Fog01_blend_gamma = fog {
     Fog01_wTurb
     blend_gamma 2
}
#declare Fog01_inverse = fog {
     Fog01_wTurb
     inverse
}
#declare Fog01_range = fog {
     Fog01_wTurb
     range 7, 20
     blend_gamma 2
}
#declare Fog03_rotate = fog {
     Fog01_inverse
     type 3
     rotate z*45
}
//...

Bill P.

Post a reply to this message