"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-6C16F7.17001225022004@news.povray.org...
> In article <403d0e51$1@news.povray.org>,
>  "Hughes, B." <omn### [at] charternet> wrote:
>
> > I like not having to use object {ThisSphere}
>
> 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.
---snip---
> I also think it makes things a bit clearer to have some kind of wrapper
> for the object name.

Yes, I can see the reasoning here. This whole discussion, of what I didn't
skip anyway, was causing my mind to wander and think about it being possible
to write a piece of the SDL likened to the way a #macro() is now but with
far more interaction. And so, in that way, I thought of it as allowing for
subsets of a new kind of SDL which are callable at any time; same as the
program code itself. Maybe the term would be soft-code rather than
hard-code. From that idea I could see it as not needing every designation
such as would be if a material{} had to always be written out in full for a
simple color.

Anyway, I think I'm understanding it better now that I spoke up. It surely
is of the realm of programming before the final usage could come into play.
But I feel I've backtracked here by rehashing what's probably already been
said.

Bob H.

Post a reply to this message