So you all say : is bad....

ID:269241
 
Apr 24 2005, 11:40 am
I've seen lots of people say ":" is bad to use in coding, and you should use "." instead. Well my question is, how can I define the variable more clearly, so I can actually use "."
- EXAMPLE -
if(istype(M,/mob/Player))
  M:Coolness ++

If I try to use a "." there, I would get Undefined Variable M:Coolness"

Also I have seen in coding I think...
mob
  Player
    var
      stat
        stat2

Is that possible?
Apr 24 2005, 11:43 am
ITG Master wrote:
I've seen lots of people say ":" is bad to use in coding, and you should use "." instead. Well my question is, how can I define the variable more clearly, so I can actually use "."
- EXAMPLE -
> if(istype(M,/mob/Player))
>   M:Coolness ++
>

If I try to use a "." there, I would get Undefined Variable M:Coolness"

if(istype(M,/mob/Player))
  var/mob/Player/P = M
  P.Coolness++
Apr 24 2005, 11:50 am
In response to Jon88
Thank you.
Apr 24 2005, 12:10 pm
The reason that the : operator can so often be bad is because it's basically telling the compiler not to check it. In other words, something like this would compile with the : operator:

obj/var/obj_variable = "This variable belongs to /obj."

//mob/verb/test() will give a runtime error, but will compile
mob/verb/test()
    src << src:obj_variable


The above would compile, but it would give a runtime error since it can't read a non-existant variable. The . operator, on the other hand, would catch the mistake before it turns into a runtime error.

What Jon said is correct:

if(istype(M,/mob/Player))
    var/mob/Player/P = M  
    P.Coolness++


I just want to elaborate a little bit:

The method that Jon used is called type casting. On BYONDscape, YMIHere has a great article on the subject.

By the way, the following is NOT legal:

mob
  Player
    var
      stat
        stat2


If you want to organize things like that, use datums or lists! =)
Apr 24 2005, 12:16 pm
In response to Wizkidd0123
 
> obj/var/obj_variable = "This variable belongs to /obj."
> 
> //mob/verb/test() will give a runtime error, but will compile
> mob/verb/test()
>     src << src:obj_variable
>

The above would compile, but it would give a runtime error since it can't read a non-existant variable.

Heh you should test this out yourself :). It will not compile. When using the colon operator it will check to see if the variable is within the datum you defined the variable as or one of its children. Should none of them have it it won't compile.
Apr 24 2005, 12:25 pm
In response to Wizkidd0123
Thanks for answering my questions, and it helped my learn new BYOND coding things, but my last question is here, with this code I can use a ":" and it works, but using a "." doesnt...
mob
    proc
        Shop()
            var/Buyable = input("What unit would you like?")in list("Soldier","Mage")
            switch(Buyable)
                if("Soldier")
                    var/Soldier = new/mob/Units/Soldier(null)
                    src = /mob/Player
                    src.Unit_List.Add(Soldier)
Apr 24 2005, 12:41 pm
In response to ITG Master
What you're doing there is manually setting the value of src, which isn't a good idea here. Furthermore, you're setting it to a type path; an uninitialized object.

You're also abusing usr (by default, input() boxes are sent to usr). Read the usr lecture.

Anyway, the following would work:

mob
    proc
        Shop()
            if(!istype(src,/mob/Player))
                return
            switch(input(src,"What unit would you like?")in list("Soldier","Mage"))
                if("Soldier")
                    var/mob/Units/Soldier/S = new()
                    var/mob/Player/P = src
                    P.Unit_List.Add(Soldier)


I want you to note a few things:

var/mob/Units/Soldier/S = new()


Notice the way I'm giving as much information to the compiler as possible about the soldier. That's a good rule of thumb: give the compiler as much information as you can when defining variables.

var/mob/Player/P = src


I want you to realize here that since DM is a loose-typed language, while this tells the compiler to think of P as a /mob/Player, it doesn't actually guarantee it! We guaranteed that earlier in the proc:

if(!istype(src,/mob/Player))
    return


Now, while I hoped you've learned more about type casting from the above, I want you to release a much easier way to do this: define your proc under /mob/Player in the first place!

mob/Player/proc/Shop()
    switch(input(src,"What unit would you like?")in list("Soldier","Mage"))
        if("Soldier")
            src.Unit_List.Add(new/mob/Units/Soldier)


Since Shop() now belongs to /mob/Player, src is guaranteed to be a /mob/Player!
Apr 24 2005, 12:44 pm
In response to Wizkidd0123
Wizkidd0123 wrote:
By the way, the following is NOT legal:

> mob
>   Player
>     var
>       stat
>         stat2
>



It depends on what you've defined and what you haven't.
stat
  parent_type=/obj


If you had that defined, the above would be legal.
Apr 24 2005, 12:45 pm
In response to Theodis
Theodis wrote:
Heh you should test this out yourself :). It will not compile. When using the colon operator it will check to see if the variable is within the datum you defined the variable as or one of its children. Should none of them have it it won't compile.

Doh! Forgot about that!

Here's a better example of colon failure:

obj/var/obj_variable = "This variable belongs to /obj."

//atom/proc/test() will give a runtime error if the atom is not an obj, but will compile
atom/proc/test()
    world << src:obj_variable
Apr 24 2005, 12:46 pm
In response to ITG Master
/mob/player is an object type, not an actual object. You need something like in the example given you previously in this thread.
var/mob/player/M=src
src.Unit_List.Add(Soldier)

However, the way you did that makes it appear as though the src will always be of type /mob/player. If that is so, you can define the proc to be owned by that type instead.
mob/player
    proc
        Shop()
Apr 24 2005, 12:47 pm
In response to Hell Ramen
Hell Ramen wrote:
It depends on what you've defined and what you haven't.
stat
>   parent_type=/obj

If you had that defined, the above would be legal.

Good point. =P

Actually, the parent_type = /obj line isn't even needed for legalization. The following alone would legalize it:

stat
Apr 24 2005, 12:49 pm
In response to Wizkidd0123
Wizkidd0123 wrote:
> mob
>     proc
>         Shop()
>             if(!istype(src,/mob/Player))
>                 return
>             switch(input(src,"What unit would you like?")in list("Soldier","Mage"))
>                 if("Soldier")
>                     var/mob/Units/Soldier/S = new()
>                     var/mob/Player/P = src
>                     P.Unit_List.Add(Soldier)
>


If you are going to call your variable S, don't forget to change P.Unit_List.Add(Soldier) to P.Unit_List.Add(S)
Apr 24 2005, 12:52 pm
In response to Loduwijk
Loduwijk wrote:
If you are going to call your variable S, don't forget to change P.Unit_List.Add(Soldier) to P.Unit_List.Add(S)

Ungh. I'm making too many stupid mistakes today. =P

Thanks, Loduwijk. =)
Apr 24 2005, 1:17 pm
In response to Wizkidd0123
Don't mind this post...I was to late.