View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000182LDMudEfunspublic2004-11-26 21:232009-10-05 16:47
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionwon't fix 
Summary0000182: New efun: deep_call_other()
DescriptionShort: 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.
TagsNo tags attached.
External Data (URL)

Relationships

related to 0000136 new LDMud 3.5 Enforce the call of super functions. 

Activities

lars

2004-11-26 23:15

reporter   ~0000219

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)

Gnomi

2004-12-02 05:28

manager   ~0000230

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.)

zesstra

2009-09-26 15:06

administrator   ~0001292

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).

zesstra

2009-09-30 14:43

administrator   ~0001364

If no last minute objections I will close this as wont fix.

Issue History

Date Modified Username Field Change
2004-11-26 21:23 lars New Issue
2004-11-26 23:15 lars Note Added: 0000219
2004-12-02 05:28 Gnomi Note Added: 0000230
2009-09-26 15:06 zesstra Note Added: 0001292
2009-09-26 15:07 zesstra Relationship added related to 0000138
2009-09-26 15:17 zesstra Relationship deleted related to 0000138
2009-09-26 15:17 zesstra Relationship added related to 0000136
2009-09-30 14:43 zesstra Note Added: 0001364
2009-09-30 14:43 zesstra Status new => feedback
2009-10-05 16:47 zesstra Status feedback => closed
2009-10-05 16:47 zesstra Resolution open => won't fix