That doesn't sound easier to maintain to me. Instead it sounds like I would have to search all around the code to see what actually happens when a player logs out, instead of looking at one concise procedure. I would also prefer to have a saving system that is independent of the logout code, which can be called anywhere it is needed.
The time it takes to write ..() is negligible. It doesn't make sense to write things into your code just in case you might use them later. Do you define a whole list of variables that you might not even use? No, so why make a call to a parent that doesn't exist?
It would make sense to have multiple Logout()s if you have more than one mob type that may have clients connected to them. Such as, one mob that is supposed to stick around even when the client disconnects, and another that is supposed to get deleted. Then you might want to have a parent proc that just sends a "so-and-so left the game" message, and saves some stuff. However, it's obvious that in Gokussj's project this is not the case - all players connect to the same mob type, so a single Logout() is probably sufficient. If my assumption is false then well, Gokussj is failing to let us know about a very important aspect to the problem.
In reality it is just a matter of preference. I don't think what you are saying is wrong but I certainly wouldn't do it that way. I apologize if you thought I was attacking you - I'm a very sarcastic and argumentative person. But I wouldn't go so far as to call you incompetent or idiotic. Part of the reason I enjoy arguing is because I learn something when I am proven wrong, but you seem to be more interested in masturbating your own ego. Have fun with that :)
Calling ..() on Logout is a good measure actually. It may not have a default action at the moment but if you suddenly thought of using a library that uses it, it will. The same goes for world/New. Considering this kind of stuff is a good practice.
| |
That is a good point, including a library in the middle of development might require the parent call. Even so, as the programmer, shouldn't you be aware of when your code needs modification to work with a library? Furthermore, how can you predict just when the parent call should be made? You might want your code to execute before the library, or the other way around...
| |
The thing that irritates me is when someone who doesn't know what they're talking about (i.e. ignorance), and knows they don't know what they're talking about, pretends they do and presses it.
| |
That depends on where you think a default action should be. Well, one thing is for sure. It should definitely not be after a del src line. If you ask me to choose between anticipate or modify, I say both.
| |
Metamorphman wrote:
The thing that irritates me is when someone who doesn't know what they're talking about (i.e. ignorance), and knows they don't know what they're talking about, pretends they do and presses it. Wow, you are really making an effort to insult me. Perhaps I don't know what I am talking about. But do you really think I would be aware of that, and then purposely argue what I knew to be wrong? No way. Jemai1 wrote: If you ask me to choose between anticipate or modify, I say both. touché | |
Magicsofa wrote:
That doesn't sound easier to maintain to me. Instead it sounds like I would have to search all around the code to see what actually happens when a player logs out, instead of looking at one concise procedure. I would also prefer to have a saving system that is independent of the logout code, which can be called anywhere it is needed. Actually, every time I write code, I am constantly trying to think of other ways I could use this code, and then I try to make sure the code I write is accessible in a variety of ways to be more useful to the code base as a whole. An entire different topic is project management, which is actually partly handled with ..() calls in DM. Since the compiler compiles code files in alphabetical order, it might actually make more sense to have different pieces of a single procedure's functionality spread out across different code files. The ..() calls ensure that every change to the proc is supported, and unless you can't keep track of your own code base, this type of project management is minimal. The problem case you raise assumes the programmer is an idiot and can't use text searching functionality built into the code editor, or looses track in his brain where parts of his code lay, which is highly unlikely to happen with someone who knows what they're doing.. which is the type of person I originally said should be using this. New programmers should be trying to keep things easier to read and understand for them. More advanced programmers are going to spread things out because they can think of their code in different perspectives and more than one perspective at a time. At any rate, it is actually good practice, also, for new programmers to use ..() calls in overriding procs because they are likely to forget they overrode it somewhere else. And if they did not, they could report problems with code here on the forum without even realizing the entire reason it doesn't work is because the last alphabetical override is the only valid code in the proc (this actually happened last week). | |
I definitely see what you mean about making code portable. It's a practice that I feel I have just barely touched the surface of, and that I should focus on getting better at.
Maybe I need some more experience and knowledge to fully understand this idea of 'splitting' a function between different files. I certainly do this type of thing with object types - I'll have one file to handle mob movement, another to handle properties and initialization, another to handle verbs, and so on. But I tend to think of a proc as a unit of code, an in-out machine that performs a specific task (like "update the HUD"). And I think of parent procs as the generalized unit of code, while the "children" do stuff specific to that object type. For example, say I want to program a variety of powerup items that the player can get. Each one may do very different things; it might change the value of a variable belonging to the player, or change a property of several external objects. Or it might draw crazy things all over the screen. Each one requires a unique function (unless you want to go wild with if statements). However, all of them share certain functionality: Like telling the player "You got (blah) powerup!" and then removing itself from the map. In that case I'd have a bunch of unique object types with a Get() proc that always call the parent first. But I feel like this isn't really what you are talking about... | |
this totally went off topic lol.
| |
Having multiple overrides is necessary if you want to do things modularly. You might want to plug in a save system that saves things upon log out and another system that communicates to the world upon log out. Having a separate log out call for each module is easier to maintain, and makes more sense than squashing it all into one log out proc. Hope you enjoyed that lesson.
And even if you do put everything in a single log out proc it is still good practice to have parent calls because it can save time in case you ever do want to override it somewhere else. So it does improve code, and you're an idiot.