If you want to override a proc several times (for organizational purposes) how is the order of execution determined (including libraries) and how can the behavior of ..() be predicted (as in which proc will be considered the default proc).
I've used this type of thing before and it always seemed to work out but I thought I should find out why it works.
ID:148683
 Nov 12 2002, 1:27 pm
|
|
|
Nov 12 2002, 2:09 pm
|
|
Garthor
 |
..() calls the proc of the parent. Thus, mob/NPC/Monster/Rat/proc/Stupid() would call mob/NPC/Monster/proc/Stupid(), which would call mob/NPC/proc/Stupid(), which would call mob/proc/Stupid(), if they all had ..() in them. Also, there should be no confliction with libraries anywhere. If you've overridden the proc, then the overriding thing (the thing you overrided it with... what's that called?) will be run. Overriding a proc multiple times would call the proc for the current type of mob the thing you are calling it for is. If you mean you've overridden it multiple times under the same type, than that is very stupid, and won't work.
|
Garthor wrote:
..() calls the proc of the parent. Duh, aka "default proc" Thus, mob/NPC/Monster/Rat/proc/Stupid() would call mob/NPC/Monster/proc/Stupid(), which would call mob/NPC/proc/Stupid(), which would call mob/proc/Stupid(), if they all had ..() in them. Duh, that's what you just said. Also, there should be no confliction with libraries anywhere. If you've overridden the proc, then the overriding thing (the thing you overrided it with... what's that called?) will be run. Uhhh...a proc? Overriding a proc multiple times would call the proc for the current type of mob the thing you are calling it for is. Overriding a proc (no matter how many times) doesn't cause any proc to be called, calling a proc causes a proc to be called. If you mean you've overridden it multiple times under the same type, than that is very stupid, and won't work. I think you need to re-read your post to find out what is truly very stupid. I suppose by your definition, every library that was ever made that used built in DM procs (New, Del, Move, etc.) is very stupid and won't work because they still expect/allow the users of the library to overload those same procs (1 + 1 = 2 = multiple overrides under the same type). Try this code and tell me if it works (not a useful example, but to show that it does work): mob New() world << "test" ..() New() ..() world << "test2" | |
You repeatedly misunderstood my posts. If you override a proc, when you call that proc for a mob, if it's been overriden for that mob, it will call that mob's version of the proc. The parent proc remains the same. When you override a proc for the same mob type twice, then it won't work how you want it to, it will only execute one, and I've never done it before, so I don't know which one will be called. Maybe it'd give you an error. Also, when you said "Uhhh...a proc?", you didn't understand me. I meant what the proper term for something that has overridden something else is, but there probably isn't a word... overrider?
| |
When you override a proc for the same mob type twice, then it won't work how you want it to, it will only execute one, and I've never done it before, so I don't know which one will be called. This does actually work. You can override a proc as many times as you like (I believe only DM supports this.. most other languages probably vomit when you try to do it). What order it goes in is a bit uncertain.. The one that actually defines the proc (the one with proc/ before it) should be called last. The rest probably just go in sequential order down the code tree. -AbyssDragon | |
Garthor:
...so I don't know which one will be called. I did overreact a bit and you were probably trying to help but you basically answered my post by saying you don't know the answer. This does actually work. You can override a proc as many times as you like (I believe only DM supports this.. most other languages probably vomit when you try to do it). What order it goes in is a bit uncertain.. The one that actually defines the proc (the one with proc/ before it) should be called last. The rest probably just go in sequential order down the code tree. That makes sense and seems to go along with what I've observed so far. The types of procs I need it for are ones that need to be customizable to each game while leaving the original library intact. I use a few basic operations (such as deleting a client in a boot proc, removing them from lists, etc.) but want the person using the library to be able to add in extra steps incase they are in the middle of a game or need other special circumstances accounted for. If my defined proc is called last, then this will work just fine. If it is called first then it could cause some problems. There are other ways to do it but this seemed the most convenient way. Thanks | |