|
Re: the annoying keys "key" and "value"
by toolic (Bishop) on Dec 23, 2010 at 20:48 UTC
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: the annoying keys "key" and "value"
by LanX (Saint) on Dec 23, 2010 at 21:21 UTC
|
Where did you find this and what does the documentation there say about the motivation?
Maybe sorting hashes?
Or associative structure allowing repeated keys?
Maybe for representation of multi-value elements of an HTML form?
Please help us understand that you're posting a serious real question and you are not just trying cheap trolling...
| [reply] |
|
|
I presumed a level of experience that is much less common than I expected, hence the seeming cryptic nature of my message. Sorry.
This pathological representation of a hash is in wide-spread use due to some idiotic standards adopted early in the history of XML. It shows up in Perl frequently when dealing with XML. In the most recent situation I've encountered, WordPress XML-RPC returns its custom fields in such a representation. There are even some WordPress XML-RPC libraries in some languages that require you to pass in an ordinary hash rather than this pathological (array of hashes) representation of a hash -- thereby hiding the pathology.
I was hoping to discover the generic name for this pathological hash representation to search for packages that specifically deal with it so as to hide the pathology.
| [reply] |
|
|
IIRC XML allows multiple children-elements of same tag-name (like - as already mentioned - some HTML-Form elements do) and they are ordered.
Ordinary hashes in perl don't allow multiple keys of same name and have no order.
I doubt there is any common name, you might call it "XML-structure".
| [reply] |
|
|
|
|
|
|
|
|
|
<struct>
<member>
<name>foo</name>
<value><i4>1</i4></value>
</member>
<member>
<name>bar</name>
<value><i4>2</i4></value>
</member>
</struct>
Is this part of the scheme your problem?
In my eyes it's XML which is pathological here, and CPAN modules just try to reflect the structure to avoid
ugly bugs caused by information loss when cross transforming data...
For instance:
- Can you guaranty that no implementation XML-RPC-parser will ever try to pull information out of the order of the "members"?
- Do they handle repeated keys alike?
And if you think it's so well defined, so why don't you just hack your own map_to_pathological(%hash) routine which simplifies your task?
CPAN authors might show interest in your patch, or you publish your own add-on module.
| [reply]
[d/l]
[select] |
|
|
I don't understand , how it is pathological (having properties that cause unusually bad behaviour, especially regarding correctness or performance)?
| [reply] |
|
|
|
|
|
Re: the annoying keys "key" and "value"
by Anonymous Monk on Dec 23, 2010 at 21:31 UTC
|
I don't know what you'd call it, but if for some reason you had a data structure where the key was easier to work with if it weren't stringified, that structure might make sense.
Of course, in that case, I would've used a flat array (key1, val1, key2, val2, ...) or a array of "tuples" (key1,val1, key2,val2, ...). So it's hard to defend the structure you describe, even if I have seen it a lot in verbose APIs -- the serialization of which makes it even less defensible. | [reply] |
|
|
> key was easier to work with if it weren't stringified,...
good point! for example references are difficult to be used as simple keys.
> I would've used a flat array (key1, val1, key2, val2, ...) or a array of "tuples" ([key1,val1], [key2,val2,] ...).¹
I'd rather prefer the later, far easier to combine with map or grep.
1) missing code tags added
| [reply]
[d/l]
[select] |