Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
var a,b,c = get()
world << "[a] [b][c]" // outputs "Hello, World!"
return list("Hello","World","!")
Or Python.
Multiple var assignment from a list is supported in a few languages (Perl is another common one, and therefore PHP also), but it's a tricky business. I suspect it's not feasible, although I'd be lying if I said I never gave it any thought before myself.
Here is an example on where it would help me out.

// Without
list/LST = demo()
VAL = LST["Value"]
TXT = LST["Text"]
LST = LST["List"]

// With
var list/LST,VAL,TXT = demo()

proc/demo(){return list("List"=list(),"Value"=444,"Text"="blabla")}
In response to Kozuma3
In that case it'd likely be more like the following, given the behaviour of BYOND's lists:
// Without
list/LST = demo()
VAL = LST[1]
TXT = LST[2]
LST = LST[3]

// With
var list/LST,VAL,TXT = demo()

proc/demo(){return (list(), 444, "blabla")}
Dunno if it would work when declaring variables or as such if ever implemented q.q

var demo = {"world << "Hello, World!"}
var list/strings = parseStrings(demo)
demo = strings[1]
strings = strings[2]

var demo = {"world << "Hello, World!"}
var list/strings
demo,strings = parseString(demo)

var a,b,list/l = list()
a = findtext(string,"\"")
b = findtext(string,"\"",a+1)
l["[l.len+1]"] = copytext(string,a+1,b)
string = copytext(string,1,a) + "string [l.len]" + copytext(string,b+1)
else break
return list(string,l)
In response to Kozuma3
All the examples here smell a lot like Primitive Obsession, and you should definitely apply the Replace Array with Object refactoring on all of em.

For that first example:
var/data/data = demo()
// can pass data to anything else that uses data
// (without having to pass each var again separately)
// can call data procs for data-specific behavior

return new/data(list(), 444, "blabla")


New(list/list, value, text)
src.list = list
src.value = value
src.text = text

// presumed procs for data-specific behavior here

For the parser example, I'd move parseStrings() to a new datum, string_parser.
Instead of parseStrings() returning a list, make it set vars of the string_parser: string, strings. See if the function has a more appropriate name in the context of a "string parser" type.
If it gets any more complicated, you can cleanly work within string_parser.

DM is object-oriented, so everyone should be used to making new types for every distinct "set of data with associated behavior" (that's what an object is), especially when refactoring.

The advantages of having defined structure in your code over an on-the-fly list of who-knows-what, should be obvious.
Makes sense, still would be nice to have.
I've often wished for tuples in DM as an incredible syntactic sugar, but have always gotten by with datum. I think it would be significant effort to incorporate into the language--lua has it easy as everything is a table in that language. If DM implemented it, would it be funneled through lists internally? I don't know about how it is now, but lists used to have a not-insignificant overhead. And if lists are declared constant, would that decrease the overhead at all?

Login to reply.