Sorry - this started short but got longer.
1) Trivial point: the entry for split also says that the syntax is
split variable {using | with} primaryDelimiter [and secondaryDelimiter]
I always find myself typing "by" instead of "using" or "with", and it seems
to work. Is that some strange freak, or just a third synonym which has been
implemented, but not documented?
2) The Transcript dictionary for split says:
If you specify a secondaryDelimiter, the key for each
element is the last portion of each part of the variable,
separated from the element�s content by the
secondaryDelimiter. For example, if the primaryDelimiter is
return and the secondaryDelimiter is space, the first word
of each line of the variable is placed in an array element
whose key is the second word of the line.
I think (and hope) this is 180 degrees. I think the key is the first
portion, the value assocatiated with that key the second.
put "key1 value of k1,key2 value of k2,key3 value of k3" into x
split x by comma and space
put the keys of x
-- key1
-- key2
-- key3
put x[key2]
-- the value of k2
3) Looking at this again, I wonder if the reason the confusion arose is that
the behavior with one delimiter and the behaviour with two are inconsistent.
(This is arguably more an xtalks issue - if someone shouts,I'll move it
there, but while we're on the subject...). I find the behaviour of split
with one delimiter not as useful as I'd hoped. I'd like the following to
happen
put "key1,key2,key3" into x
split x by comma
put the keys of x
-- key1
-- key2
-- key3
put x[key2]
-- 2
Instead, what we get is
put "key1,key2,key3" into x
split x by comma
put the keys of x
-- 1
-- 2
-- 3
put x[2]
-- key2
Obviously, either form can be scripted fairly trivially, so nobody is too
totally inconvenienced either way. But I think that in combination, they're
inconsistent. Working forward from the current implementation of split-1d,
it would be reasonable to assume that in split-2d there will be one element
in the array for each (in the above example) item, with the value for each
item being the first word - that's what is documented, but not what happens.
Conversely, working back from the current implementation of split-2d, it
would be reasonable to expect that there would be one element for each item,
with the key for the item being the first word of it.
Now here's where the confusion bites:
put "key1 value of k1,key2 value of k2,key3 value of k3" into x
split x by comma and space
put the keys of x
-- key1
-- key2
-- key3
put "key1 value of k1,key2,key3 value of k3" into x
split x by comma and space
put the keys of x
-- key1
-- 2
-- key3
In other words, if two delimiters are specified; but on any item selected by
the primary delimiter, the secondary delimiter isn't found, then Rev/MC
behaves as if the secondary hadn't been specified. That feels very odd to
me. It also points to a way that I could get what I want ^H^H^H^H that the
behaviour could be modified in a subtle way, unlikely to mess up existing
code that uses split, making behaviour in this example more (I'd argue)
intuitive; - and also providing a way to get the alternative behaviour for
split1d. That is, if two delimiters are specified; and the second isn't
found for any item defined by the first, then make the key for that entry in
the array be the whole of that item (and I guess make the value be the
index?).
Does this make sense to anyone?
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
