Lets get back to the code problem, please.
| |
-._.DreamBunny._.- wrote:
Gokussj99 taught me to use spawn instead of sleep to make loops. I didn't say use spawn for everything just for that particular thing you showed me lol.. please read http://www.byond.com/docs/ref/index.html the spawn proc in reference or press F1 in DreamMaker. spawn is basically a delayed block of code. sleep actually halts whatever is going on until the sleep is over spawn does not. | |
Spunky_Girl wrote:
With a name like "Gokussj9", why would you ever take their advice regarding programming? He obviously has no idea how sleep() and spawn() work at all. You have no idea what you're talking about. And for the record I didn't tell that person to use spawn in that loop. He never even asked me about this issue. And using (:) colons is not malpractice it is great for referencing something indirectly if you know it will exist. It's situational. | |
And if you find a "situation" where you would use a colon, then it would be bad programming design. It is better to typecast and reference directly than it is to "hope" and "assume" (or as you stated "know"... same thing >_>) it will be there.
This is the runtime search operator. It is used to access a property of a var that is not explicitly prototyped. If the variable doesn't have the specified variable, a run-time error occurs. As the DM Reference (found through F1 in Dream Maker) says, it will just spit out a runtime error. Aren't we all trying to avoid these runtime errors as much as possible in our games/applications? They're annoying and flat out unprofessional, so why would you use a design that could possibly result in generating one? It is malpractice to use the : operator to reference "indirectly" as you say. | |
Spunky_Girl wrote:
And if you find a "situation" where you would use a colon, then it would be bad programming design. It is better to typecast and reference directly than it is to "hope" and "assume" (or as you stated "know"... same thing >_>) it will be there. My most common usage of ":" is after an if(istype()), in procs such as Bump() or Cross(), as such it's 100% guaranteed to be the correct type. It's not malpractice, it's just a nicer way to lay out your programming. Although I do agree that overuse of ":" can be messy and break things, if used properly it's perfectly fine. | |
if(ismob(a)) The above is much safer and better design than... if(ismob(a)) Also... Rushnut wrote: ...as such it's 100% guaranteed to be the correct type.This is the assumption and hope I was talking about. | |
I pretty specifically said istype().
if(istype(a,/mob/monster))a:attack()
Or something. It's not pleasing on my eyes to have to define a var and use that for one instance, when I can just use the above and be 100% safe with it. | |
What I wrote was the same idea. My point, which you apparently miss, is that you should be typecasting and then using the (.) operator.
if(istype(a,/mob/monster)) | |
Spunky_Girl wrote:
What I wrote was the same idea. My point, which you apparently miss, is that you should be typecasting and then using the (.) operator. Define: Should What is my benefit? When I know the type, and I know it has the correct vars. | |
You can rename the variable as part of refactoring, and the compiler will catch all the references for you, and you don't embarrass yourself at runtime. With runtime resolution, refactoring in general is just that bit more iffy.
That should is a British should, which means "You'd be a bit silly not to". | |
Actually using the : operator to a var that isn't defined will give a compile time error.
But, yeah I guess that's one benefit, but then you should be tracking things better. I mean I'm not saying that using : is better than using ., it's just not the devil. | |
No, but it's also not really ... sensible, in the general use case? It's the lazy man's option, almost.
| |
I guess this is kind of like the goto situation all over again, and since I'm a forerunner of burn goto, I guess I should shut my trap.
| |
Not quite. Your mention of the compile-time error got me tinkering, and it reminded me that while it does catch some things, it doesn't catch all. For example, this compiles but obviously does not run okay:
client The goto situation is almost purely a readability/maintainability thing in the sense it obscures logic a bit, and is harder for a programmer to read. : actually sacrifices some of the compiler's good graces, by contrast. | |
Yeah, that's why I didn't press the point further because it can still be broken.
| |
I guess he just has to be told by someone who has actually remained active on these forums in the past few years for him to finally see the light. Understandable I guess.
| |
Not at all, I am well aware of who you are, Spunky, I simply realised the likeness to the goto argument, which I am firmly against. So I guess that whilst I certainly won't stop using the : operator because I highly doubt I'll be silly enough to misuse it, I can accept that ultimately it's just not something for everyone.
| |
Rushnut wrote:
...because I highly doubt I'll be silly enough to misuse it...Until that one occurrence when fecal matter is spread across the room via a running fan of some sort on one of your games/applications because of it, when it was just a careless oversight in the first place. | |
> if(ismob(a)) The above is much safer and better design than... > if(ismob(a)) How are these two different? ismob() ensures its a mob, not using : just seems like something you should avoid using if you're just starting out. And even if it does fuck up once, it's probably the most easiest thing to fix... But I do use goto in specific cases, what's so bad about goto? :I | |
SuperSaiyanX is one of the best programmers I know.
You are just simply ignorant, name is not indictive of skill, it is simply what you choose to affiliate yourself with.