Re: better flatten()?
- Posted by petelomax Jul 27, 2015
- 1647 views
I noticed that flatten2() does not seem to handle nested strings correctly.
The revised version above yields the much more reasonable "abc, def, ghi, jkl, mno, pqr, stu, vwx, yz", thanks
So I made my own attempt to better handle this behavior and I wrote two functions: flatten_all() and flatten_seq().
Without adequate testing, may I quickly suggest:
-- -- string type borrowed from std/types.e -- type string( object x ) -- unchanged if not sequence(x) then return 0 end if for i = 1 to length(x) do if not integer(x[i]) then return 0 end if if x[i] < 0 then return 0 end if if x[i] > 255 then return 0 end if end for return 1 end type -- -- flatten a sequence, preserving nested strings -- function flatten_seq2( sequence s1, string delim = "" ) sequence s2 = "" object s1i for i = 1 to length( s1 ) do if i!=1 then s2 &= delim end if s1i = s1[i] if atom( s1i ) or string(s1i) then -- (edit: wrong test) s2 &= s1i else s2 &= flatten_seq2( s1i,delim ) end if end for return s2 end function
That string_array thing just looked wrong to me, like it was only ever going to work at a single nested level. Of course flatten() needs to do something sensible when passed a tree of words.
Oh, I had to remove join because I was making it recursive, it now calls itself rather than flatten_all, and that just feels more sensible.
I'm thinking it is reasonable to say that when processing non-string stuff you should not use a delimiter, and if you do specify one there is a fairly strong implication that you are expecting a single string back.
To that end I sneaked in a type check on delim.
I'm not absolutely against the idea of two functions, but I'm not convinced we really need that split yet either.
Pete