Split/join tools for your coding pleasure!

ID:96729
 
Jun 10 2010, 11:08 pm (Edited on Jun 17 2010, 6:40 am)
Split txt into a list of strings, using sep as the field separator value:

proc/splittext(txt as text, sep as text)
    var
        list/accum
        start;end

    accum = new/list()
    start = 1
    do
        end = findtext(txt,sep,start)
        accum += copytext(txt,start,end)
        start = end + lentext(sep)
    while(end)
    return accum


Create text from list lst, using sep to separate the elements:

proc/joinlist(list/lst,sep as text)
    var
        txt as text
        i
    txt = lst[1]
    for(i=2,i<=lst.len,i++)
        txt = addtext(txt,sep,lst[i])
    return txt


Enjoy!


edit: changed while() loop to a do while() loop.
Jun 11 2010, 4:41 am
Just a few picky things, well, it's mostly all the same thing. You initialize variables after their declaration, but you initialize them to a static value anyway, so I don't see why you don't just initialize them where they're declared.

You could also make usage of the '.' variable here, such that:
proc/joinlist(list/lst,sep as text)
    var
        i
    . = lst[1]
    for(i=2,i<=lst.len,i++)
        . = addtext(txt,sep,lst[i])

(Just modifying your example)
Jun 11 2010, 5:12 am
The built-in params2list() and list2params() might be a bit faster, and support associative lists ;)

(although I don't think you can specify your own separator in them)
Jun 11 2010, 5:14 am (Edited on Jun 11 2010, 9:21 am)
DivineTraveller wrote:
Just a few picky things, well, it's mostly all the same thing. You initialize variables after their declaration, but you initialize them to a static value anyway, so I don't see why you don't just initialize them where they're declared.

It's a matter of style, I think. I like to keep my declarations segregated and place the initialization closer to where they are used in the code. However, when functions are super-short, as these are, it wouldn't bother me to have it either way.

You could also make usage of the '.' variable here, such that:
> proc/joinlist(list/lst,sep as text)
>     var
>         i
>     . = lst[1]
>     for(i=2,i<=lst.len,i++)
>         . = addtext(txt,sep,lst[i])
>

(Just modifying your example)

Thanks for the tip. :)

However, in my code, I am declaring the variable 'txt as text', which I am then returning. Therefore, the values in lst should only be text, as should the return value. It makes sense to me that the compiler/runtime should (does it?) toss an error if/when it determines that this is not the case.


edit: fix typo
Jun 11 2010, 5:16 am
Lewzer wrote:

However, in my code, I am declaring the variable 'txt as text', which I am then returning. Therefor, the values in lst should only be text, as should the return value. It makes sense to me that the compiler/runtime should (does it?) toss an error if/when it determines that this is not the case.

To be honest, I only use 'as blah' when I'm working with verbs. I don't really think DM pays attention to them anywhere else, though someone will probably correct me on that eventually.
Jun 11 2010, 11:43 am
DivineTraveller wrote:
To be honest, I only use 'as blah' when I'm working with verbs. I don't really think DM pays attention to them anywhere else, though someone will probably correct me on that eventually.

If you add said proc to a client's verbs list then 'as blah' will matter.
Jun 11 2010, 11:44 am
Metamorphman wrote:
DivineTraveller wrote:
To be honest, I only use 'as blah' when I'm working with verbs. I don't really think DM pays attention to them anywhere else, though someone will probably correct me on that eventually.

If you add said proc to a client's verbs list then 'as blah' will matter.

Then why bother not making it a verb in the first place?
Jun 12 2010, 8:49 am
DarkCampainger wrote:
The built-in params2list() and list2params() might be a bit faster, and support associative lists ;)

(although I don't think you can specify your own separator in them)

Everyone here is so helpful! :) Thank you. I'm new here, so the tips are appreciated.

Here are a couple of situations where I find these very convenient:

I'm using something very similar to this to implement "themes" in my game (this is just an example).

proc/find_icon(atom/O,theme="gothic",root="themes")
    var
        found = 0
        path = "[O.type]"
        split
    while(path)
        if(fexists("[root]/[theme]/[path].dmi"))
            found = 1
            break
        else
            split = splittext(path, "/")
            split.Remove(split.len) // remove last
            path = joinlist(split, "/")
    
    // ... do something more ...



...in league with params2list.

client/SomeSortOfWindowPlacementProc()
    var/list
        winparams
        pos; size
        xy;wh
        
    winparams = params2list(winget(src, "main_window", "pos;size"))
    
    pos = splittext(winparams["pos"], ",")
    xy = list(text2num(pos[1]),text2num(pos[2])
    
    size = splittext(winparams["size"], "x")
    wh = list(text2num(size[1]),text2num(size[2])
    
    // ... jointext() them later?

Jun 16 2010, 6:06 am
DivineTraveller wrote:
Lewzer wrote:

However, in my code, I am declaring the variable 'txt as text', which I am then returning. Therefor, the values in lst should only be text, as should the return value. It makes sense to me that the compiler/runtime should (does it?) toss an error if/when it determines that this is not the case.

To be honest, I only use 'as blah' when I'm working with verbs. I don't really think DM pays attention to them anywhere else, though someone will probably correct me on that eventually.

Actually, you're right, mostly (I think)! This is mentioned in Lummox JR's post here, under the heading Not My Type. However, according to the help files, the istype() function does pay attention to the declared type. If I want to enforce the arguments to only be of type text, I still have to explicity check them.

Thanks for bringing this up!