In article <403d0e51$1@news.povray.org>,
 "Hughes, B." <omn### [at] charternet> wrote:

> Ahh yes, thanks for that clarification. I suspected as much but it was
> looking to me like everything was to be built in the same way as accessing
> it later.

You could create a language in such a way, but it would be quite 
strange...actually, JavaScript is a little similar. But none of the 
syntaxes I've seen suggested for POV would do it this way.


> I like not having to use object {ThisSphere}, so this is a good thing I
> think. Minimized scripting in the same vein as not needing parent wrappers,
> which I believe you actually mentioned back in the thread someplace, could
> be nice. Maybe not clear until learning what's what, but easier to write.

I think you might be referring to my "#declare MyObj = object {MyObj 
translate...}" example. I would actually prefer some kind of wrapper, 
though maybe not of that exact form. Something like:

scene {
    MyObj;
    AnotherObj;
    AndAnotherOne;
    SomeProcedureThatReturnsAnObject();
    ObjectMaker.MakeAnObject();
}

Basically, any statement that results in an object puts an object into 
the scene when used within a scene {} block. Outside a scene block, the 
object just gets ignored. Otherwise you'll run into annoyances when you 
call something that returns an object that is only desired some of the 
time. Say you have a procedure that does something to an object and 
returns that object for convenience, but you sometimes need to call it 
but don't need the returned object. Without the scene{} block 
restriction, you'd have to do something like declare a dummy variable 
just to hold the object you don't want...annoying.
I also think it makes things a bit clearer to have some kind of wrapper 
for the object name.


> > Yes. You're assuming you would have to do everything in a much more
> > complex fashion, this is not the case. The final result could be very
> > similar to the current POV language in general use.
> 
> Okay. But, admittedly, it would still become more code-like for the writers
> of it. Yet, presumably, easier to use the result.

Well, it won't make the internals of a lens flare system any easier for 
non-coders to understand, but it will make it easier for them to use it. 
Objects are typically seen as "black boxes", they can be very complex 
inside but nobody has to care about that, they only use the stuff on the 
outside.


> Regardless, I think all this will come down to a widened dividing 
> line between casual artists and data-crunchers.

I don't think so. It will mean more is possible entirely within POV 
script, so the "data crunchers" won't have to go to external tools, and 
the casual users have a much shorter distance to go before they can 
understand and create similar things. POV-artists and POV-coders, rather 
than POV-artists and C++/Java/Python-coders-who-export-POV-code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message