View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000258 | LDMud 3.5 | Efuns | public | 2004-11-26 23:10 | 2016-01-26 19:04 |
| Reporter | Assigned To | Gnomi | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000258: Shadow efuns: next_shadow/query_shadow() instead of shadow(ob,0) | ||||
| Description | Short: 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 object. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
I would suggest to include the querying functionality in object_info() as: OINFO_SHADOWS: 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? |
|
|
I'm in favor of removing. 3.3 is for compatibility, 3.5 for beauty. |
|
|
object_info(ob, OI_SHADOW_NEXT/_PREV/_ALL) does what was proposed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:10 |
|
New Issue | |
| 2009-09-26 16:05 | zesstra | Note Added: 0001296 | |
| 2009-09-29 09:19 | Gnomi | Note Added: 0001332 | |
| 2009-09-29 14:47 | Coogan | Note Added: 0001351 | |
| 2009-09-30 14:49 | zesstra | Product Version | 3.2.8 and before => |
| 2009-09-30 14:49 | zesstra | Summary | Shadow efuns => Shadow efuns: next_shadow/query_shadow() instead of shadow(ob,0) |
| 2009-09-30 14:49 | zesstra | Project | LDMud => LDMud 3.5 |
| 2009-09-30 14:50 | zesstra | Note Added: 0001365 | |
| 2011-02-14 17:01 | zesstra | Note Added: 0001988 | |
| 2011-02-14 17:01 | zesstra | Status | new => feedback |
| 2011-02-14 17:02 | zesstra | Target Version | => 3.5.0 |
| 2011-02-14 17:39 | Gnomi | Note Added: 0001990 | |
| 2012-12-06 19:22 | zesstra | Relationship added | related to 0000596 |
| 2015-04-29 22:10 | zesstra | Status | feedback => confirmed |
| 2015-05-01 21:04 | Gnomi | Assigned To | => Gnomi |
| 2015-05-01 21:04 | Gnomi | Status | confirmed => assigned |
| 2016-01-26 19:04 | Gnomi | Note Added: 0002275 | |
| 2016-01-26 19:04 | Gnomi | Status | assigned => resolved |
| 2016-01-26 19:04 | Gnomi | Fixed in Version | => 3.5.0 |
| 2016-01-26 19:04 | Gnomi | Resolution | open => fixed |
