I find this as buggy.. or I've missunderstood something:
kaos@jenna daemon $ pike -e 'array a = ({ ({ "foo", "bar" }) }); write( "1: %O\n2: %{%O\n%}\n3:%{%O\n%}\n", a, a, a[0] );' 1: ({ /* 1 element */ ({ /* 2 elements */ "foo", "bar" }) }) 2: "foo"
3:"foo" "bar"
That is: why only "foo" in case 2 above? I expected to see ({ /* 2 elements */ .... })
//K
The bug would rather be in case 3. It seems that %{ is difficult to get a grip on for many people, but it is intended to work like this: The argument (or result, in the case of sscanf) is an array of elements. _Each of these elements_ is an array of positional values, which match the various % operators _inside_ the %{. So to get the "bar" part, just add another %O. Of course, it becomes even more useful when you use different conversions:
Pike v7.6 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
write("1: %{%s %07d\n%}", ({({"foo",3}),({"baz",42})}));
1: foo 0000003 baz 0000042 (1) Result: 27
In your case 3, the first element of a[0] is a string, not an array. So in this case I would have expected an error. But apparantly there is some kind of DWIM here, which of course confuses things.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
The bug would rather be in case 3. It seems that %{ is difficult to get a grip on for many people, but it is intended to work like this: The argument (or result, in the case of sscanf) is an array of elements. _Each of these elements_ is an array of positional values, which match the various % operators _inside_ the %{. So to get the "bar" part, just add another %O. Of course, it becomes even more useful when you use different conversions:
Oh, right. I've actually used this with mappings by casting them to array to get the ({ ({ key, value }), ({ key, value })... }) out of it... heh
Pike v7.6 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
write("1: %{%s %07d\n%}", ({({"foo",3}),({"baz",42})}));
1: foo 0000003 baz 0000042 (1) Result: 27
In your case 3, the first element of a[0] is a string, not an array. So in this case I would have expected an error. But apparantly there is some kind of DWIM here, which of course confuses things.
yep, guess it is, since I'm used to it being there, and didn't realize it was a special case, so I applied it to the first case in error..
thanks//K
pike-devel@lists.lysator.liu.se