Just a recap discussion on usr and src.

ID:1483284
 
Jan 28 2014, 11:54 am
(See the best response by Stephen001.)
I've been discussing this with someone for a while now. They said that they were using usr in a verb.

However, from my understanding, usr doesn't necessarily mean "user". Instead, src means "source" and is what initially called the verb or what is actually the object.

If this is correct, how often should usr be used and how often should src be used?

How I basically understand this is from an old Attack verb I made years ago that helped me realize the differences a bit.

mob/verb/Attack()
    for(mob/M in get_step(src,src.dir))
        if(M.health == 0)
            M.Death()
        else
            M.health -= 1

mob/verb/Death()
    src << "This is usr, or who initially clicked the Attack verb: [usr]."
    src << "This is src, or who \"M\".Death was called on, or just M inside of Attack(): [src]."


I just wrote that in here, pardon any errors. However, what I'm basically trying to bring up is whether or not what Death() writes is true. Just to gain a full, clear, hardened understanding of it for both myself and others who bring up this topic.
Jan 28 2014, 1:59 pm
Best response
usr is the thing that calls the verb (or proc, but that gets very shady pretty quick), and src is the thing the verb lives on.
Jan 28 2014, 3:33 pm
It's fine to use usr when you know that there is a usr and there's a point to it. I only ever use it in verbs, and if necessary, I often pass the usr as a mob argument somewhere if the need arises. I don't use usr if I can get away with src (like in mob verbs).

Really, the problem that comes about when using usr is that the usr is null or it's not what the programmer wanted.
Jan 28 2014, 5:34 pm
Although "no put usr in proc" has been repeated over and over it's technically okay to use it in a proc so long as you're aware of what calls the proc.

However a big part of real-world programming is anticipating possible future changes and planning ahead for them, and having a proc rely on usr is bad design since you'd either have to constantly test the proc in every situation to see if it still works the way it should, which is why it's better to avoid using usr in a proc altogether.

You should always develop something simple. If you're doing something more than once put it in a function (otherwise known as a proc).

Another piece of advice is to never rely on BYOND's default functionality such as Click() but to always override it at /atom level and call your own procs. It really helps you down the line when you need to make modifications to global events such as clicking on an object and you're only overriding Click() in one place.

src changes depending on the context. In theory it points to the current object to which the proc/verb belongs, but you can override the src variable at will if desired. It's still safer to rely on src than it is to rely on usr, because changes to src are easier to track.

In theory usr could be checked to see if client input was involved in any action you end up in, which could still make it useful for purposes such as debugging/logging.
Jan 29 2014, 1:55 am
Stephen basically said this, but I want to say something too :D

usr is the person who exucuted the command
src is the person you want the command to be excuted on
Jan 29 2014, 5:56 am
I'd also like to emphasize on the "no put usr in proc" quote that Lazarus mentioned for anyone who passes by on the topic.
Jan 29 2014, 6:09 am
The problem with usr, is less that it can be inaccurate, and more that it's simply not completely accurate.

Usr is typed to /mob.
src is typed to the type of the owner of the verb/proc.

Not understanding usr's proper use leads to worse habits, like embedding behavior in the wrong types, failure to cast properly, leading to abuse of the look-up operator as opposed to the path operator, and in general, leads to a programmer that is incapable of thinking in logical, clear ways.