clipka wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>>> So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
>>> existing one?
>> The imperative nature, plus the current syntax for object (and
>> texture/pattern/et al) creation.
>>
>> Ie, we DON'T need
>>
>> new SDL.Object.Sphere {
>>   Radius: 4.0f;
>>   Center: new SDL.Unit.Vector3(4.5f,1.5,3.0f);
>>   Texture: new SDL.Pattern.Texture {
>>    Pigment: new SDL.Pattern.Pigment {
>>     Pattern: SDL.Pattern.Predefined.Solid;
>>     Color: new SDL.Unit.Vector3(1.0f,0.5f,0.0f);
>>    }
>>   }
>> }
> 
> I take it as understood that we do *NOT* want any such syntax in a POV 4 SDL.
> Yes, indeed, I'd rather stick to the current SDL than use such a monster.
> 
> That's why I kept lamenting about the shortcomings of Lua and the like in this
> particular respect.
> 
> 
lol

Was thinking about this a bit. One could get the same syntax as now, 
mostly, or almost, and still get "access" the sorts of things above, but 
it requires some compromising on what is possible, and how. As well as 
maybe some minor changes to existing code. Here is how:

You have explicit or implicit declaration of objects by name. Explicit 
would be something like:

declare my_object as sphere;
declare my_object2 as box;
//Set attributes.
...

Implicit would be something like:

parse(
   sphere {...}
   box {...}
)

In other words, the "existing" SDL get parsed exactly as it does now, 
and all you have to do is either enclose the code in a "parse" command, 
or use something like 'parse_file("existing.pov");'. From the standpoint 
of people using the SDL that already exists, the result is entirely 
transparent.

Now, in the '//Set attributes' part of the first example, you get 
basically two things:

sphere.parse_table(list my_table);

and attributes like:

sphere.translation
sphere.rotation
sphere.scale
sphere.{everything else}

The parse_table is the list of things "done to" the object, is 
indexable, and you can add to it, and it parses "existing" SDL commands. 
The . parts are the "current" result of the matrix operations that took 
place in that table. One could have command to "re-run" the table, add 
to it, delete things from it, etc. And, from the perspective of 
something "coding" SDL, again, functions would exist to "add to" that 
table, as though they where using the existing SDL.

This means a tiny bit more overhead in the parse stage, since it has to 
build the tables for each object, and track them. But, it also means 
that the existing SDL remains basically the same in construct, even if 
its used a tad differently, you can nearly add to and change things the 
same way, **but** the actual "language" level can work more like a true 
program, without the complicated and confusing macro system now used to 
do most things, and with animation and other things handled, optionally 
as part of the "code" executing, and not via some reparse of the SDL.

Similar tricks would likely be possible for handling textures and other 
things. In effect, you get access to the SDL level if you need it, 
otherwise, you declare all your "static" objects, either SDL control any 
animation, or when possible, do that via the "language" level of the 
code. And, there is no conflict between what was **basically** a markup 
language, and what is program. Similar to how HTML is "clearly" 
distinct, for the same reason, from PHP, Java, or anything else that is 
used to "change it" dynamically. In a lot of ways, what little looping 
other other functions we do have in the SDL are shoehorned on. That 
really isn't going to change, unless you divorce the SDL *from* the flow 
control somehow imho.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message