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|
|Summary||0000182: New efun: deep_call_other()|
|Description||Short: New efun deep_call_other()|
From: Daniel von Dincklage <firstname.lastname@example.org>
Date: Mon, 22 Jun 1998 00:53:36 +0200
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
> void 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)|
Short: Another sort of deep_call_other() ?
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.
||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|