Am 13.12.2016 um 11:00 schrieb clipka:

> (A)
> 
>     #declare Fnord = dictionary {
>       Foo: 42,
>       Bar: sphere { <0,0,0>, 1 }
>     }
...
> (C)
> 
>     #declare Fnord = dictionary {
>       .Foo: 42,
>       .Bar: sphere { <0,0,0>, 1 }
>     }

Here's another case study showing how (A) might be disadvantageous:

    #declare Value = "Bar";
    #declare Fnord = dictionary;
    #declare Fnord.Foo = Value;

In (A) notation, the equivalent would be:

    #declare Value = "Bar";
    #declare Fnord = dictionary {
      Foo: Value
    }

But if the identifier `Value` on the right-hand side is evaluated to
"Bar", wouldn't a user also expect, with some legitimacy, the identifier
`Foo` on the left-hand side to be evaluated in the same manner? Thus, a
user may be fooled into expecting the following to work:

    #declare Key = "Foo";
    #declare Value = "Bar";
    #declare Fnord = dictionary {
      Key: Value
    }

In (C) notation, it would instead be:

    #declare Value = "Bar";
    #declare Fnord = dictionary {
      .Foo: Value
    }

Here, the mandatory dot gives the user a hint that there is /something/
different about the way the two identifiers act.


There's also another, much more far-reaching rationale to pick the dot
notation: Some day or another we'll want to overhaul the entire Scene
Description Language, and replace it with something similar but more
powerful while at the same time much more self-consistent.

One part of the deal would be to demote parameters (such as the
"diffuse" in the "finish" block) from reserved keywords to something
much more akin to "variables". We would also want users to be able to
define their own data structures that behave in exactly the same way, so
that users might e.g. define their own parameterizable geometric shapes.

However, in such a world it could become increasingly difficult to tell
apart parameters from genuine variables - and one possible solution to
that problem might lie in adopting the dot notation for parameters,
while using "undotted" identifiers for variables defined elsewhere; e.g.
a finish definition might end up looking like this:

    finish {
      .diffuse:    rand(R);
      .specular:   1 - .diffuse;
      .reflection: .specular * ReflectionFactor;
    }

Looking familiar? ;)

Post a reply to this message