POV-Ray : Newsgroups : povray.documentation.inbuilt : dictionary container types Server Time: 17 Feb 2019 22:49:29 GMT
  dictionary container types (Message 11 to 19 of 19)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Jim Holsenback
Subject: Re: dictionary container types
Date: 23 Nov 2016 16:43:34
Message: <5835c736$1@news.povray.org>
On 11/23/2016 10:04 AM, clipka wrote:
> The changes to array syntax and behaviour don't fit into the
> "Dictionary" section; they should instead be in the "Array" section.

thanks for keeping me honest: 
http://wiki.povray.org/content/Reference_Talk:Array


Post a reply to this message

From: clipka
Subject: Re: dictionary container types
Date: 23 Nov 2016 17:17:17
Message: <5835cf1d$1@news.povray.org>
Am 23.11.2016 um 17:43 schrieb Jim Holsenback:
> On 11/23/2016 10:04 AM, clipka wrote:
>> The changes to array syntax and behaviour don't fit into the
>> "Dictionary" section; they should instead be in the "Array" section.
> 
> thanks for keeping me honest:
> http://wiki.povray.org/content/Reference_Talk:Array

I think I got you confused.

The information I provided in the earlier post was for the entire bundle
of changes in the `feature/dictionary` branch currently waiting to be
tested and merged. The branch has grown to become somewhat of a
misnomer, and `feature/containers` would be a more fitting name by now,
as besides introducing the new `dictionary` container type it also
contains improvements to the classic old-school integer-indexed `array`
container.

All the information you put in the numbered-list section starting with
"Array elements will no longer have to be all of the same type [...]"
applies to arrays, not dictionaries.

It's ok (and, if I am asked, desirable) to have the dictionary-related
stuff in a separate section.


Also, typo:

"There has been a Change that removes than restriction."
                                        ^^^

I'm also noticing right now that the comments in the example section are
a bit inconsistent; please replace "testing" and "removing" with "test"
and "remove".


Post a reply to this message

From: Jim Holsenback
Subject: Re: dictionary container types
Date: 23 Nov 2016 18:27:26
Message: <5835df8e@news.povray.org>
On 11/23/2016 12:17 PM, clipka wrote:
> Am 23.11.2016 um 17:43 schrieb Jim Holsenback:
>> On 11/23/2016 10:04 AM, clipka wrote:
>>> The changes to array syntax and behaviour don't fit into the
>>> "Dictionary" section; they should instead be in the "Array" section.
>>
>> thanks for keeping me honest:
>> http://wiki.povray.org/content/Reference_Talk:Array
>
> I think I got you confused.

no doubt ... back when all this happened i was /not/ following the 
goings on, but now i'm finding time to get caught up.


Post a reply to this message

From: Jim Holsenback
Subject: Re: dictionary container types
Date: 24 Nov 2016 14:08:01
Message: <5836f441$1@news.povray.org>
On 11/23/2016 12:17 PM, clipka wrote:
> I think I got you confused

lol ... ok enough with the back-and-forth already ;-)

not sure why i kept wanting to treat as two different subjects ... 
hopefully i've cleared things up: 
http://wiki.povray.org/content/Reference_Talk:Array and we can stick a 
fork in this one!


Post a reply to this message

From: clipka
Subject: Re: dictionary container types
Date: 24 Nov 2016 15:01:33
Message: <583700cd$1@news.povray.org>
Am 24.11.2016 um 15:07 schrieb Jim Holsenback:
> On 11/23/2016 12:17 PM, clipka wrote:
>> I think I got you confused
> 
> lol ... ok enough with the back-and-forth already ;-)
> 
> not sure why i kept wanting to treat as two different subjects ...
> hopefully i've cleared things up:
> http://wiki.povray.org/content/Reference_Talk:Array and we can stick a
> fork in this one!

Almost there.


"Additional points to consider are as follows:"

- Please add a note that this is new in 3.7.1. ;)

- I'd remove the "will" from "1. Array elements will no longer...".

- I'd collapse 1.a and 1.b into a single paragraph.

- I'd collapse 3.b and 3.c into a single paragraph.

- I'm noticing only just now that points 4. and 5. apply only to
dictionaries. I think something should be done to make this clearer.

- I'm noticing only just now that 6. is a duplicate of 4.

- I'd add a few end-of-sentence markers (aka full stops) to the items. ;)

- I'd personally prefer a bullet list, as there's no hierarchy among the
items.


Also, I'd move anything related to dictionary initializers to the "Array
Initializers" section, possibly with a line of text or two.


Post a reply to this message

From: Jim Holsenback
Subject: Re: dictionary container types
Date: 25 Nov 2016 12:00:36
Message: <583827e4$1@news.povray.org>
On 11/24/2016 10:01 AM, clipka wrote:
> Am 24.11.2016 um 15:07 schrieb Jim Holsenback:
>> On 11/23/2016 12:17 PM, clipka wrote:
>>> I think I got you confused
>>
>> lol ... ok enough with the back-and-forth already ;-)
>>
>> not sure why i kept wanting to treat as two different subjects ...
>> hopefully i've cleared things up:
>> http://wiki.povray.org/content/Reference_Talk:Array and we can stick a
>> fork in this one!
>
> Almost there.

argh ... you're stifling my creativity ;-)


Post a reply to this message

From: clipka
Subject: Re: dictionary container types
Date: 13 Dec 2016 09:17:02
Message: <584fbc8e$1@news.povray.org>
Am 22.11.2016 um 08:35 schrieb Mike Horvath:
> On 11/19/2016 7:34 PM, clipka wrote:
>> Am 20.11.2016 um 01:10 schrieb Mike Horvath:
>>> On 11/19/2016 2:26 PM, clipka wrote:
>>>>     // alternative
>>>>     #declare Fnord = dictionary {
>>>>       .Foo: 42,
>>>>       .Bar: sphere { <0,0,0>, 1 }
>>>>     }
>>>
>>> Will the dotted syntax allow people to use strings like ".declare" or
>>> ".texture"? I don't think it should.
>>
>> No -- just like with variable identifiers, keywords are not allowed
>> there.
> 
> I still think the dot is superfluous.

Think about it:

    #declare Foo = "Dang";
    #declare Bar = "What";

    #declare Fnord = dictionary {
      Foo: 42,
      Bar: sphere { <0,0,0>, 1 }
    }

Which of the following would that supposedly be equivalent to?

(A)

    #declare Fnord = dictionary;
    #declare Fnord.Foo = 42;
    #declare Fnord.Bar = sphere { <0,0,0>, 1 }

(B)

    #declare Fnord = dictionary;
    #declare Fnord[Foo] = 42;
    #declare Fnord[Bar] = sphere { <0,0,0>, 1 }

aka

    #declare Fnord = dictionary;
    #declare Fnord.Dang = 42;
    #declare Fnord.What = sphere { <0,0,0>, 1 }

I think mandating the dot is a nice way to prevent such ambiguity; plus,
it makes things a tiny bit more consistent: Whatever you'd normally put
after the dictionary identifier, you just pop it into the initializer.


Post a reply to this message

From: clipka
Subject: Re: dictionary container types
Date: 13 Dec 2016 10:00:06
Message: <584fc6a6$1@news.povray.org>
Am 13.12.2016 um 10:17 schrieb clipka:

>> I still think the dot is superfluous.
> 
> Think about it:
> 
>     #declare Foo = "Dang";
>     #declare Bar = "What";
> 
>     #declare Fnord = dictionary {
>       Foo: 42,
>       Bar: sphere { <0,0,0>, 1 }
>     }
> 
> Which of the following would that supposedly be equivalent to?

To elaborate more on that point: When designing the syntax for
dictionary initializers, one could come up with the following
alternatives to all denote the same:

(Intent)

    #declare Fnord = dictionary;
    #declare Fnord["Foo"] = 42;
    #declare Fnord["Bar"] = sphere { <0,0,0>, 1 }

(A)

    #declare Fnord = dictionary {
      Foo: 42,
      Bar: sphere { <0,0,0>, 1 }
    }

(B)

    #declare Fnord = dictionary {
      "Foo": 42,
      "Bar": sphere { <0,0,0>, 1 }
    }

(C)

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

(D)

    #declare Fnord = dictionary {
      ["Foo"]: 42,
      ["Bar"]: sphere { <0,0,0>, 1 }
    }

Note how variants (A) and (B) are fundamentally incompatible: If the key
can be a string literal, it is legitimate to also expect other string
expressions to work, and this would include plain references to string
variables. Thus, a consistent implementation of (B) would also allow for
the following:

    #declare Key1="Foo";
    #declare Key2="Bar";
    #declare Fnord = dictionary {
      Key1: 42,
      Key2: sphere { <0,0,0>, 1 }
    }

This however would take on a completely different meaning under variant (A).

Now one could rule in favour of either A or B, and I think both have
their merits. Which is why I think it wise to go for neither of them,
and instead opt for variants that are collision-free not only with
respect to each other, but even with respect to the entire set of
_possible_ alternatives.


Post a reply to this message

From: clipka
Subject: Re: dictionary container types
Date: 13 Dec 2016 10:43:39
Message: <584fd0db$1@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.