View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000419LDMudImplementationpublic2005-11-28 07:442018-01-29 22:57
Reportertobij Assigned Tolars 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0000419: protected sefuns inconsistency
DescriptionSimul efuns marked as "protected" can be called from usual objects, but only if the concerned sefun is one of the 256th first sefuns (and not called by the 'call_other mechanism').

I definately didn't expect that protected sefuns can be called at all, but whatever behaviour is attributed to protected sefuns should be consistent and not depend on mysterious factors as "how early" the sefun is defined.

Also, what would one want to "protect" sefuns from if one wants them to be callable? From getting called via call_other? And if, why?
TagsNo tags attached.
External Data (URL)

Activities

lars

2005-12-04 23:24

reporter   ~0000444

All simul-efuns must now be public in order to be called. This is to enable the construction of simul-efun objects via inheritance: this way they can use protected functions internally without having to make them available to everybody.

Issue History

Date Modified Username Field Change
2005-11-28 07:44 tobij New Issue
2005-12-04 23:24 lars Status new => resolved
2005-12-04 23:24 lars Fixed in Version => 3.3.713
2005-12-04 23:24 lars Resolution open => fixed
2005-12-04 23:24 lars Assigned To => lars
2005-12-04 23:24 lars Note Added: 0000444
2006-02-28 20:58 lars Status resolved => closed
2010-11-16 10:42 lars Source_changeset_attached => ldmud.git master 314446cc
2010-11-16 10:42 lars Source_changeset_attached => ldmud.git master 1287bb6f
2018-01-29 19:59 lars Source_changeset_attached => ldmud.git master 314446cc
2018-01-29 19:59 lars Source_changeset_attached => ldmud.git master 1287bb6f
2018-01-29 22:57 lars Source_changeset_attached => ldmud.git master 314446cc
2018-01-29 22:57 lars Source_changeset_attached => ldmud.git master 1287bb6f