DelimitedList method for Node only elements

[runz0rd]

For #6

[msftclas]

Hi @runz0rd, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.

TTYL, MSBOT;

[mousetraps]

Thanks for the PR! Left some comments and +1 after that!

It would also be good to add a test for this behavior to NodeApiTest.php (mock object is probably the way to go.)

[mousetraps]

This approach won't work for DelimitedList\QualifiedNameParts or DelimitedList\ExpressionList, which both have the possibility of producing a token instead of a for some constructs. Additionally, it probably makes sense to preserve empty elements (by producing null values in their place)

One approach might be to simply define the delimiter as a constant on DelimitedList. For most of them, TokenKind::CommaToken should suffice (TraitSelectOrAliasClauseList and QualifiedNameParts are the only exceptions). Additionally, in order to reduce duplication, we could refactor parseDelimitedList to replace the delimiter parameter with a constant access on the class.

[runz0rd]

Would it make sense for DelimitedList to have a $delimiter prop instead, to keep them more flexible? We already have DelimiterLists that do not have a constant delimiter and there may be more.

[mousetraps]

We already have DelimiterLists that do not have a constant delimiter and there may be more.

We do? Sounds like a bug 😃. Could you elaborate?

In general, we keep away from holding any "descriptor" properties on Nodes because the memory cost of additional properties is 12-16 bytes each (depending on 32 bit or 64 bit), which very quickly adds up on large code bases.

[runz0rd]

In #103 we should parse QualifiedNameList with TokenKind::BarToken delimiter, but in most cases its TokenKind::CommaToken.
But its probable I just misunderstood your suggestion ("simply define the delimiter as a constant on DelimitedList") 😄

[runz0rd]

I noticed a // TODO consider allowing empty delimiter to be more tolerant in parseDelimitedList, so if we allow insertion of empty delimiters (if there are none), the getListElements can return even key values of children.
If this does sound okay to you, how would you prefer to represent these empty delimiters?

[roblourens]

It looks like getElements now fills this role. Please correct me if I'm wrong.