View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000182 | LDMud | Efuns | public | 2004-11-26 22:23 | 2009-10-05 18:47 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000182: New efun: deep_call_other() | ||||
| Description | Short: New efun deep_call_other() From: Daniel von Dincklage <vondincklage@usa.net> Date: Mon, 22 Jun 1998 00:53:36 +0200 Type: Feature State: Unclassified See also: p-990204-1, f-011011 (Sorry for taking that long to reply) On Fri, 19 Jun 1998, Daniel von Dincklage wrote: >> - A deep_call_other efun >> Calls the function in all inherits, this is esp. useful for the >> Move-Object-driverhooks - You could use deep_call_other,"init" >> there and never have to worry about people forgetting the ::init >> in their files again. On Sat, 16 Jan 1999, Logic wrote: > > I can see a problem here; what happens when you have an init() that looks > like: > > void init() > { > initialize_things(); > do_stuff(); > ::init(); > } > > In the case of deep_call_other(), you don't have an opportunity to do any > initialization before going up the inheritance chain. Of course, that could lead to some confusion. In addition, my current implementation calls the functions in the inherits in a more or less random manner. Please note that the ::init() in your example will still work, providing quite a big level of additional confusion. The simple solution to this problem is simply to only use code/variables declared in the same class, as the current init() was declared. Adding this restriction to init() would be a bit too much, so one could have a second "deep_init" function. This works quite well, as I use the deep_pre_create-Hooks here quite often. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
| related to | 0000136 | new | LDMud 3.5 | Enforce the call of super functions. |
|
|
Short: Another sort of deep_call_other() ? From: Alfe Date: 2001-10-11 Type: Feature State: New See also: f-990203-17 Mir wuerde schon reichen, wenn ich irgendwie einstellen kann, dass man alle lfuns ver-||-ern soll oder ver-,-en oder ver-&&-en (also alle aufrufen bis true kommt, bis false kommt oder unabhaengig vom ergebnis) |
|
|
A generally available efun deep_call_other I would consider a security risk. In some objects functions are overridden because of security reasons (just like nomask simul_efuns). Normal objects should not be able to call these functions anyway. (For program initialisation it would be sufficient to restrict it for use in the master and simul_efun just like set_this_object.) |
|
|
Gnomi is quite right. And if my init() calls already in a chain all the inherited init(), I don't want deep_call_other() to do that again, when it follows the chain. I think, it would make much more sense to solve the issue suggesting to enforce the call of super functiony by any programs re-defining a function (0000136). |
|
|
If no last minute objections I will close this as wont fix. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 22:23 |
|
New Issue | |
| 2004-11-27 00:15 |
|
Note Added: 0000219 | |
| 2004-12-02 06:28 | Gnomi | Note Added: 0000230 | |
| 2009-09-26 17:06 | zesstra | Note Added: 0001292 | |
| 2009-09-26 17:07 | zesstra | Relationship added | related to 0000138 |
| 2009-09-26 17:17 | zesstra | Relationship deleted | related to 0000138 |
| 2009-09-26 17:17 | zesstra | Relationship added | related to 0000136 |
| 2009-09-30 16:43 | zesstra | Note Added: 0001364 | |
| 2009-09-30 16:43 | zesstra | Status | new => feedback |
| 2009-10-05 18:47 | zesstra | Status | feedback => closed |
| 2009-10-05 18:47 | zesstra | Resolution | open => won't fix |
