I'm attaching yuqk fork documentation for its updated text{} object 
implementation (text.txt). Most subjects have been touched upon in other 
posts.

One not mentioned, is that the text{} and sphere{} objects have some new 
trial type checking in the debug compile of yuqk. I acted on the idea 
because text{} creates union{} or merge{} objects of single character 
text{} objects. Users cannot get at the underlying text{} objects. This 
means using text{TextID} isn't really correct - though it will mostly 
(always?) work.

Using the sphere{} as another example, it's possible today to code 
something like:

     #declare Light00 = light_source{...}
     ...
     #local SphereShiftedUp = sphere {Light00 translate ...}

and the parser will act on the light source identifier without complaint 
as a generic object.

The thinking is, perhaps, setting the parser up so users can use an 
object{} wrap where they don't care about the 'object' type being acted 
upon, but a sphere{} wrap when they want to be sure it's really a sphere 
identifier. Perhaps this a method of extending type checking over what 
is available with yuqk's setidtypes.inc and id_type(_id) capability.

(The internal method for this uses a dynamic_cast though - which is 
slow. Why this feature trial is only active in the debug compile of yuqk 
- which is already slower due the extra sanity checking it does.)

Sinking into the detail a bit more, the identifier definition and 
reference mechanisms today in the parser are less consistent than they 
should be.

We have cases where users can reference previously defined identifiers 
and modify only certain aspects of them creating a new object, texture 
or feature in an object oriented way; other cases where, for example, 
sphere{ID} is effectively the same as writing object{ID ...object 
modifiers...} - and cases like warp{}s where we'd like to be able to 
define an identifier for later reference but we cannot.

Bill P.

Post a reply to this message

Attachments:
Download 'text.txt' (49 KB)