> I agree there is no technical limitation. But I can see drawbacks. In the
> current syntax, we write
> 
> #declare my_sphere = sphere
> {
>    0, 1
>    pigment {White}
>    translate <1,2,3>
> }
> ..../...
> trace (my_sphere, ...)
> 
> Once the sphere has been created (= after the ending '}' of the syntactical
> block), the sphere stays how it is and we have no mean to apply a new
> transform to it afterwards. The only way I see to fake this is to create a
> new object and transform it:
> 
> #declare my_sphere_2 = object {my_sphere translate <4,5,6>}
> 
> But the first sphere remains present (even if it had no_image, no_shadow
> ....).
> 
> 
> The new syntax might allow such code:
> 
> my_sphere = sphere
> {
>    0, 1
>    pigment {White}
>    translate <1,2,3>
> }
> ..../...
> 
> my_sphere.translate y;
> 
> trace (my_sphere, ...)
> 
> And you get what you want, for animations for example, provided you are
> programmatically skilled enough to keep track of your objects and what
> happens to them.
> 
> My opinion (I'd rather say my 'intuition', but may change, I am not that
> proud of myself) is that if you perform transformations in different
> locations in the code, perhaps out of the scope of the current source file,
> you can never be sure for the current object's situation, and therefore for
> the end result.

#declare foo = object { foo translate <1,2,3> }

Add a few of those randomly around your code and "you can never be sure 
for the current object's situation". But aren't there times where it 
would be useful, when you know where transformations are being done? 
foo.translate(1,2,3) is just a nicer syntax for that, and also will 
probably run faster (no need to actually create a new object).

Post a reply to this message