View Issue Details

IDProjectCategoryView StatusLast Update
0000258LDMud 3.5Efunspublic2016-01-26 20:04
ReporterlarsAssigned ToGnomi  
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000258: Shadow efuns: next_shadow/query_shadow() instead of shadow(ob,0)
DescriptionShort: New shadows efuns
From: Tomba@Batmud
Date: 2001-08-25
Type: Feature
State: New

call_shadow() works like call_other, but it does NOT call any shadows and
so it always calls the functions in the object that was given as argument.

all_shadows() returns an array of objects shadowing the given object.

first_shadow, next_shadow, last_shadow are used to traverse shadows of an
TagsNo tags attached.


related to 0000596 resolvedGnomi new efuns for configuring objects and the driver 



2009-09-26 18:05

administrator   ~0001296

While I appreciate the possibility to find out the currently existing shadows and which objects are in which shadow chain, I perceive call_shadow() a) as ill-named and b) contradictory to the purpose of shadows. I believe, once a shadow has been granted, it should be ensured, that the shadow is actually called.


2009-09-29 11:19

manager   ~0001332

Hmm, all those functions can be implemented as simul-efuns. So there is no need for efuns, maybe only for the sake of consistency between mudlibs.

On the other hand I don't like the double purpose of shadow() (retrieving information about shadows and actually shadowing another object), so having first/next_shadow instead of shadow(ob, 0) is imho a prettier interface.


2009-09-29 16:47

reporter   ~0001351

I agree to Gnomi that for those who are in need of such functions, all of these can be implemented as simul-efuns.
The double purpose of shadow() should be noted as another issue.


2009-09-30 16:50

administrator   ~0001365

I just changed the title of this bug to reflect, that this deals now with only the issue of a better interface than shadow(ob,0) and moved the bug to 3.5.


2011-02-14 18:01

administrator   ~0001988

I would suggest to include the querying functionality in object_info() as:

OIS_NEXT: next shadow in chain
OIS_PREV: previous shadow in chain
OIS_ALL: array of shadowers in their correct order

Should we keep shadow() as well as it is or remove the querying feature?


2011-02-14 18:39

manager   ~0001990

I'm in favor of removing. 3.3 is for compatibility, 3.5 for beauty.


2016-01-26 20:04

manager   ~0002275

object_info(ob, OI_SHADOW_NEXT/_PREV/_ALL) does what was proposed.

Issue History

Date Modified Username Field Change
2004-11-27 00:10 lars New Issue
2009-09-26 18:05 zesstra Note Added: 0001296
2009-09-29 11:19 Gnomi Note Added: 0001332
2009-09-29 16:47 Coogan Note Added: 0001351
2009-09-30 16:49 zesstra Product Version 3.2.8 and before =>
2009-09-30 16:49 zesstra Summary Shadow efuns => Shadow efuns: next_shadow/query_shadow() instead of shadow(ob,0)
2009-09-30 16:49 zesstra Project LDMud => LDMud 3.5
2009-09-30 16:50 zesstra Note Added: 0001365
2011-02-14 18:01 zesstra Note Added: 0001988
2011-02-14 18:01 zesstra Status new => feedback
2011-02-14 18:02 zesstra Target Version => 3.5.0
2011-02-14 18:39 Gnomi Note Added: 0001990
2012-12-06 20:22 zesstra Relationship added related to 0000596
2015-04-30 00:10 zesstra Status feedback => confirmed
2015-05-01 23:04 Gnomi Assigned To => Gnomi
2015-05-01 23:04 Gnomi Status confirmed => assigned
2016-01-26 20:04 Gnomi Note Added: 0002275
2016-01-26 20:04 Gnomi Status assigned => resolved
2016-01-26 20:04 Gnomi Fixed in Version => 3.5.0
2016-01-26 20:04 Gnomi Resolution open => fixed