inputlist object

ID:262337
 
Apr 29 2005, 5:07 am
Code:
inputlist
    var
        list/L = new/list()
        Msg = ""
        Title = ""
        Def
        T = null|anything
    New(var/msg = Msg,var/title = Title,var/list/items = L,var/default = Def,var/Type = T)
        Msg = msg
        Title = title
        L = items
        Def = default
        T = Type
        return ..()
    proc/Add(var/item)
        L.Add(item)
    proc/Remove(var/item)
        L.Remove(item)
    proc/Edit(var/msg = Msg,var/title = Title)
        Msg = msg
        Title = title
    proc/Show(var/mob/M,var/default = Def,var/Type = T)
        Def = default
        T = Type
        return input(Usr=M,Msg,Title,Def) as T in L


Problem description:

main.dm:26:error: Bad input type: T
That error comes up for the last line of the code. Im guessing that the problem is the compiler cant do somthing that I thought it could. So the compiler cant recognize the value of T? I thought null and other such things were just like flags that were or read together bitwise. So any way to make this code work?

Its no biggy Im just messing around with datum. Seeing what I can design with it. I think Lummox Jr called it the abstract objects O.o.
Apr 29 2005, 5:18 am
I wondered the same thing at one time and so asked on the Byond Q&A section of the forums for explanation. It turns out, it is not that simple.

The input types (such as null and anything) used in this instance are worked specially internally. You can see that they do not actually have a value if you try to output them.
client/verb/test()
    src<<anything

Of course, if you tried to output null that work work though; because it also has a use outside of this application.

I think I suggested back in my older post that they be changed so that we can mess around with them. They should be turned into bit flags. Not only could it be used for convenience, as in what you are doing, but it could also be a more powerful way to do things as you would not need to have switch statements to take care of variable input types.
datum/input_object
    var/input_type=TEXT
    var/list/choices
client/var/datum/input_object/input_object
client/verb
    change_input_type()
        switch(input("Change to what?")in list("Text","Num","Anything"))
            if("Text")input_object.input_type=TEXT
            if("Num")input_object.input_type=NUM
            if("Anything")input_object.input_type=ANYTHING
    get_input()
        if(input_object.choices)
            return input("")as input_object.input_type in choices
        return input("")as input_object.input_type

It would be nice if we could do something like that.
Apr 29 2005, 6:42 pm
Well, the var/ bit doesn't need to be put in those arguments, so you can leave it out.

The "as T" though is something you really can't control. BYOND currently has no syntax for allowing you to substitute something into an as clause.

Lummox JR
Apr 30 2005, 2:11 am
In response to Lummox JR
Lummox JR wrote:
Well, the var/ bit doesn't need to be put in those arguments, so you can leave it out.

But well I thought it was what do you call it hmmm. Good coding? No im not being sarcastic. I really thought that was good coding. So you only need var/ when? or do you ever need it?

O.o could this create a "Lummox JR's Dos and Donts of byond coding".

The "as T" though is something you really can't control. BYOND currently has no syntax for allowing you to substitute something into an as clause.

Lummox JR
Apr 30 2005, 6:17 am
In response to Green Lime
Green Lime wrote:
But well I thought it was what do you call it hmmm. Good coding? No im not being sarcastic. I really thought that was good coding. So you only need var/ when? or do you ever need it?

To put it simply, when you're defining a proc's argument, the "var/" part is simply assumed by the compiler. If it's there, it will work, and if not, it will still work.

my_proc(var/my_argument)

is the same as

my_proc(my_argument)


However, putting the "var/" here seems redundant, and only succeeds in making the code that much more unreadable and lengthy, especially when alot of arguments are being used.

Observe:

proc/Show(var/mob/M,var/default = Def,var/Type = T)

can become:

proc/Show(mob/M,default = Def,Type = T)


Of course, alot of your variable names are absolutely horrendous, so although this change will be a big step in making your code readable, there's still work to be done. Remember, the name of a variable should be a comment in and of itself.