Re: the number of items
Posted: Tue Aug 13, 2013 5:46 pm
...leaving aside the issue of strings vs lists for the moment, because I think once that happens this discourse will change completely, but at the moment we don't have that to deal with...
And having just tested this again, the number of items of "" is 0 in either case, so you're not losing that.
The difference in the two is the number of items in "," where using the itemDelimiter you get 1 and using the itemSeparator you get 2.
In either case you end up with at least one empty item.
Whether or not that's confusing is subjective, especially given the item list example above. My opinion (and this is just mine) is that it's actually less confusing to explicitly test "if tItem is empty" rather than relying on an implicit assumption about the repeat loop. And do notice that if you don't set the itemSeparator in your handler that processes the loop there's no change in current behavior.
Both the itemDelimiter and itemSeparator have the scope of the local handler and revert to their default states afterwards.
Thus, even though I have written handlers that rely on counting items using an itemSeparator of comma and can tell the difference between empty and non-empty items by code like
they have no problem coexisting.
Returning to the strings vs lists thing for a moment: are you implying that when we get real lists you intend to keep the current paradigm. i.e., the last item or line in a list can't be empty?
? How many items are in "1,,,2,,,3" ? Aren't there empty items in that list?Given that we are used to thinking of empty as nothing, it doesn't make sense to me personally that 'the number of items of empty' should be 1 - as a list of length 1 is *something* (even if that item is empty).
If you interpret 'the number of items of empty' as being 1 then you take away something you can represent now - the empty list (one of no items). This interpretation isn't even limited to string lists that could contain empty items either, it affects all string lists. It means that there is no way to tell a function which takes a list of items that you actually mean no items.
And having just tested this again, the number of items of "" is 0 in either case, so you're not losing that.
The difference in the two is the number of items in "," where using the itemDelimiter you get 1 and using the itemSeparator you get 2.
In either case you end up with at least one empty item.
Whether or not that's confusing is subjective, especially given the item list example above. My opinion (and this is just mine) is that it's actually less confusing to explicitly test "if tItem is empty" rather than relying on an implicit assumption about the repeat loop. And do notice that if you don't set the itemSeparator in your handler that processes the loop there's no change in current behavior.
Sorry - I don't understand this at all. If this were the case, my local copy of the engine/IDE combination would be falling flat on its face, no?With this in mind the only option other is to allow choice; however I think this would actually make things worse - code written to two different delimiter standards will not be interoperable without code to bridge the gap.
Both the itemDelimiter and itemSeparator have the scope of the local handler and revert to their default states afterwards.
Thus, even though I have written handlers that rely on counting items using an itemSeparator of comma and can tell the difference between empty and non-empty items by code like
Code: Select all
if item x of tList is empty --
Returning to the strings vs lists thing for a moment: are you implying that when we get real lists you intend to keep the current paradigm. i.e., the last item or line in a list can't be empty?