Change split* to return a string_vec rather string_array

Description

Currently, `split{{ and friends return a }}string_array{{, which is a }}table[count] of string{{. However, these BiFs should return a }}string_vec{{ or }}vector of string{{ to allow for sequential iteration over the result. The problem with the current approach is not only that it is wrong modeled (the associative container does not make sense), but also that iteration over the elements, which are obviously ordered, is neither deterministic nor sequential. Presumably this mismatch exists because vectors were not available when the }}split*` functions have been created.

Environment

None

Activity

Show:
Matthias Vallentin
January 19, 2015, 8:10 PM

While I'd like to see this feature getting added, I think a new function vsplit would bloat the API, unless there is good use case for having string_set as well. I don't see that use case though. Anyone else?

Jon Siwek
January 20, 2015, 4:13 PM

My initial reaction is also to just change those functions directly to return vector of string. I'll take a look.

Jon Siwek
January 20, 2015, 5:58 PM

Bah, this is related to BIT-924: these functions are using 1-based indexing. So changing them to return a vector also begs to treat them like vectors commonly are w/ 0-based indexing. And changing the indexing scheme deserves a method of deprecating or ability to switch between a 0-based versus 1-based indexing "policy", so that we don't silently break code that people have written which depends on the original 1-based indexing.

I am thinking the easiest/quickest way is to add new functions, name them appropriately w/ intention that they'll stick around for the long haul, add a sort of &deprecated attribute to split() and friends, and then later remove those deprecated functions. Let me know if there's other opinions.

Seth Hall
January 20, 2015, 8:00 PM

Your proposal sounds great to me.

Jon Siwek
January 21, 2015, 10:48 PM

See topic/jsiwek/deprecation in bro, bro-testing, and bro-testing-private. It adds the deprecation mechanism and deprecates split* and related functions in favor of alternatives that use a string_vec.

Assignee

Robin Sommer

Reporter

Matthias Vallentin

Labels

External issue ID

757

Components

Fix versions

Affects versions

Priority

Normal
Configure