Hm...i was gonna suggest tat! Do that, and then work out the errors. I have nvr evr used the : operator, and id care to either. But since it doesnt give you errors at compile time, much mor problems will occur unchecked at runtime. Thus....dont use it at all...
| |
Let's just say this: The ':' colon operator is bad karma, it may seem fine now, but somewhere, sometime later, it'll come right back at you and bite you in the ass.
Adding on to what the other person said, this is what you are currently doing: mob/verb/Brittle_Code() Basically, turning the ':' colon operator to '.', and make the variable an actual type path would not also fix your evil ':' habits, but to fix later runtime errors later also. Here's a simple fix to this: mob/verb/Robust_Code() Or you can choose my favorite way out of a code that is bugged to hell and uses bad habits: Recode the whole thing. | |
Hiead wrote:
I myself rarely use the : operator. Although gurus may disagree(the : operator is evil, after all), I do explicitly always check the reference type before use. For example: > mob/player/var/hp=1000 Now that isn't actually code from any particular program, I just made it up as an example. I am curious to see how a guru would change this, since I did wish to handle 3 different types of /atom/movable differently, where /mob/player has a local variable hp, and where /mob/NPC has a local variable lava_count to keep track of how many times it entered lava, possibly reporting such information to the player. The checks could then be extended to handle many other types, as long as they were of type atom/movable/A. The above example is definitely the wrong way to use the : operator. You should either 1) type cast every one of those vars, or 2) call an atom proc which can be overridden for different object types, such as atom/Terrain() called with the turf as an argument. As I mentioned in another post, the only "right" way to use the : operator is when you're working with objects which may be of several very disparate types, but have the same var or proc you need to access. In all these cases the failure to group those types under a common type is a design flaw, but it's a minor one. Lummox JR | |
Justin Knight wrote:
Lummox JR wrote: Visionzzzz has started you on the right path. You have to first search for the : operator everywhere it's used. As for an example, I point you to [link] in which in an earlier post you used a simple var/lol rather than giving that var the correct type in the frist place. Lummox JR | |
Could everyone stop referring to the coding as mine? It's getting really annoying.
When you say "you did this" that sounds like I typed that all out from scratch, which I didn't. I copied it over and changed it from other items' code, which I knew that coding worked. You're making me look like a sloppier coder than I really would be, if I coded this all from scratch (don't tell me to do it from scratch, I know somebody is going to, the coding would take months to reproduce by myself, instead of a couple of weeks of editing.) Also, you guys are making it sound 'so simple to fix,' what I had to do with that coding was locate one item in your HUD, and check to see if the other item was in your selected hand. Then it checks to see if the welder has enough fuel(which is what everyone is complaining about, and it actually works in-game) and takes away fuel if it has enough. Then it deletes the two items, and replaces it with the third. It's not as simple as me being lazy and not typing out a full object path. | |
Justin Knight wrote:
Could everyone stop referring to the coding as mine? It's getting really annoying. If it isn't yours, clearly this other guy doesn't know how to use the : operator either, then. Why base your code off his work? When you say "you did this" that sounds like I typed that all out from scratch, which I didn't. I copied it over and changed it from other items' code, which I knew that coding worked. You're making me look like a sloppier coder than I really would be, if I coded this all from scratch (don't tell me to do it from scratch, I know somebody is going to, the coding would take months to reproduce by myself, instead of a couple of weeks of editing.) I wasn't implying anything about the code's origin. Either you typed it directly or you copied it from your program; same difference. Point is it's got a problem that needs correction. If that problem was not yours in origin, better to correct it so you're not working with the certain mistakes of one person and the possible mistakes of another. Brittle code is a problem precisely because of this compounding of errors, where one piece of code influences another that was not built properly. Also, you guys are making it sound 'so simple to fix,' what I had to do with that coding was locate one item in your HUD, and check to see if the other item was in your selected hand. Then it checks to see if the welder has enough fuel(which is what everyone is complaining about, and it actually works in-game) and takes away fuel if it has enough. Then it deletes the two items, and replaces it with the third. It's not as simple as me being lazy and not typing out a full object path. Yes, it's exactly that simple. Giving the object the correct path is pretty darn easy, won't screw with the code's operation, and will simplify it while also allowing you to use the . operator for better protection against runtime errors. The code's complexity has absolutely nothing to do with the ease of giving objects proper type paths; if anything it only strengthens the case for correcting the sloppy programming, because complex code will be more prone to the runtime errors you could have avoided at compile-time. In the example I pointed to, all you have to do is 1) change var/lol to a definition using the right type path, a path you already know since you were using it in istype(), 2) change the : operator to . instead, and 3) if you like, remove the type path from istype() since you no longer need it there. The complexity of the algorithm doesn't impact that process one iota. Anyway, why doggedly hang onto the wrong way of doing things when you can exert a truly miniscule effort and learn to do things right? That will vastly stabilize your code and insulate you against potential show-stopper bugs down the line. The changes you must make are ridiculously minor; in most cases in the code I've seen from you, it's as simple as giving a var the right type. Sometimes a new var with the right type is required, which is called type casting; this is also dirt simple. The fact that some of your code is complex is absolutely irrelevant; you don't risk breaking it, only strengthening it. There is no excuse whatsoever for leaving everything as-is. Lummox JR | |
Lummox JR wrote:
In all these cases the failure to group those types under a common type is a design flaw, but it's a minor one. Yay it's only minor! I do know of ways that I could change this to have just as easily removed the : operator, but it seems to me to repetitive, after checking the type of the object. Something like: turf/lava/Entered(atom/movable/A) But that would take up unnecessary RAM, no doubt(though extremely minimal). Besides the fact that the : should not provide any errors, since it only calls vars held by /mob/player, after checking to make sure that it is the /mob/player type. Anyways I'm glad to hear it's only considered a minor flaw. I'm doing something a little similar, though with a different purpose than the example, in the 8k project I am currently working on. Hiead | |
Hiead wrote:
Lummox JR wrote: > turf/lava/Entered(atom/movable/A) Nope, you've missed the boat. Although this is one way to fix the : operator situation, the method I mentioned of defining a proc is much better. However, this snippet and the one you posted earlier do not fall under the issue I said was "minor". Where the : oprator is forgiveable is only in situations where a common var or proc is used that for some reason can't or shouldn't be defined under their shared parent type--or if they have no shared parent type, which is kind of an odd situation. As I mentioned, that's a minor design flaw, and it has absolutely zilch to do with what you posted. But that would take up unnecessary RAM, no doubt(though extremely minimal). Besides the fact that the : should not provide any errors, since it only calls vars held by /mob/player, after checking to make sure that it is the /mob/player type. Like I said, this is abuse of the : operator and it should not be used that way. This is not the issue I called minor; it's just plain sloppy programming. Anyways I'm glad to hear it's only considered a minor flaw. I'm doing something a little similar, though with a different purpose than the example, in the 8k project I am currently working on. What you posted was not the minor flaw. Something completely different is considered a minor flaw. In the 8K project, however, use of the : operator is expected since space is at a premium. Such challenges are never meant to be bastions of robust programming. Lummox JR | |
If you used the var "shortcut" as a reference to an object and try to access its variables, you will have to use ':', which is bad. Assuming that it was referencing an /obj/knife , then you can simply access the variables with '.', which is 100% better in this case.
I myself rarely use the : operator. Although gurus may disagree(the : operator is evil, after all), I do explicitly always check the reference type before use. For example:
Now that isn't actually code from any particular program, I just made it up as an example. I am curious to see how a guru would change this, since I did wish to handle 3 different types of /atom/movable differently, where /mob/player has a local variable hp, and where /mob/NPC has a local variable lava_count to keep track of how many times it entered lava, possibly reporting such information to the player. The checks could then be extended to handle many other types, as long as they were of type atom/movable/A.
Hiead