No big deal, but I'm curious whether it's me or BYOND...
Doesn't compile:
proc/Suck(obj/O)
sleep(2)
if(vacuumSource == src)
if(ismob(O) && O:client) O:Die(0)
else del O
return
Compiles OK:
proc/Suck(obj/O)
sleep(2)
if(vacuumSource == src)
if(ismob(O))
var/mob/M = O
if(M.client) M.Die(0)
else del O
return
ID:259225
 Sep 16 2000, 1:38 pm
|
|
On 9/16/00 5:38 pm Guy T. wrote:
No big deal, but I'm curious whether it's me or BYOND... It looks like the obj/O declaration is taking precedence over the : operator. I wasn't aware that this was the case, and don't think it should be, given precedence from other languages. I'll discuss it with Dan; he may have a reason for enforcing this behavior. | |
It is a little known fact, but the colon operator does pay attention to the type of the left-hand side. Usually you only use it when you have not declared any type, so it basically gives you global access to all vars and procs. However, that is just a special case of the general behavior, which is to give you access to all vars and procs of objects derived from the given type. There are situations in which you can make use of that to give you better type checking than a global symbol lookup. If that is as clear as mud, I can try again. | |
That's the problem there. You should leave O typeless, because you're accessing the variable as "give me an object" and then inside of it you're doing "check to see if its a mob, and check this variable". Objects don't have client vars, and it isn't under the assumption that it could be a mob.
Not sure exactly why DM can't realize what you're trying to do, though.
That works because you're then explicitly telling it to look for a mob.
The first code would work if you left O typeless, though, or at least it should. I'm getting booted off the computer now, so I can't test it yet. =)
proc/Suck(O)
sleep(2)
...
Tsk tsk, Guy, I thought you knew better. =)