|
On Nov 29, 2015 2:09 AM, "Dirk Laurie" <dirk.laurie@gmail.com> wrote:
> I'm not claiming this is better, but some XML-to-Lua converters
> do the attributes as a table with string keys, using integer keys
> to order the keys.
>
> {height=100, width=200, fg='red', bg='green', 'height', 'width', 'fg', 'bg'}
>
> This allows standard random access, and in case you need it,
> traversal by ipairs and indexing.
It also breaks pairs(), since you have to check "is this a real attribute, or just an annoying number." In the case of a codebase you control, this isn't so bad; you can apply metatables/views to taste. In the case of XML interchange between modules, it's annoying—not least because this ordering information for attributes is definitionally not relevant to XML content.
> Of course, this use case assumes that ordered access is seldom
> needed (only for reconstructing the original XML, in the cases
> I have encountered).
I think this is a situation in interfaces where “less is more.” Some XML interfaces deliver CDATA as a separate node type by default rather than just a quoting mechanism. The interfaces misled some file format designers into making CDATA structurally significant. This caused tooling and pipeline problems.
Jay