On 2023-12-10 22:29 (-4), William F Pokorny wrote:
> 
> So... I'm now toying with the idea of making all shorthand updates,
> parse errors in yuqk and suggesting this for v4.0 too. Essentially, yuqk
> would be forcing the texture{} block specification(s), always, as a path
> to consistent overall behavior.
> 
> This idea is easier for me to swallow because I tend to assign finish{},
> normal{}, pigment{} (and interior{}) blocks to IDs before using them in
> texture{} or material{} blocks - also assigned to IDs - prior to use
> with objects. In other words, I already often code in this style. I do
> it because it makes modifications easier - but, it also avoids some of
> the subtle shifts / inconsistencies in parsing behavior which happen
> today with the texture shorthand / aspect update methods.

When I was developing RC3Wood v2.0, I found unblocked textures, normals,
etc. so difficult to shoehorn through the parser that I just made the
macros return blocks.  While this was not a shorthand update issue, the
resolution was the same: work with enclosed blocks.

> [snip]
> 
> Thoughts / comments?

I'm fine with yanking shorthand updates.  I never use the technique
anyway, so I would not miss them; and since it uses a seemingly
ambiguous syntax to merely duplicate functionality of less confusing
code, I would discourage other people from using it.

On the other hand, I would not require all finish{}, normal{} and
pigment{} blocks to be enclosed in a texture{} block.  This is too
useful and too often used in existing code to be discontinued.  I don't
know if you had this in mind, but I'm just trying to keep my position clear.

Post a reply to this message