View Issue Details

IDProjectCategoryView StatusLast Update
0000136LDMud 3.5LPC Compiler/Preprocessorpublic2010-03-15 17:45
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0000136: Enforce the call of super functions.
DescriptionI agree there is no common standard, that's why I thought about the
reserved word as a flag to functions like:

public <some keyword> void create();
or
<some keyword> public void create();

A function defined like that would then have to call (::create()) at some point
or make the compiler complain and possibly abort compilation. This way
any function with the keyword in its definition has to call the parent. In other
words not limited to return types of the function. Obviously the topmost
inherit doesn't have to call (::create()).

An alternative would be to flag overriding functions as 'wont-call-super', and have the error happen by default.

This way the proper initialisation of objects could be insured, for example.
TagsNo tags attached.

Relationships

related to 0000182 closed LDMud New efun: deep_call_other() 

Activities

_xtian_

2004-12-07 06:26

reporter   ~0000239

this is also a good idea. Note that most MUD wizards are not experienced coders (and many don't want to be), so we need all the syntactic sugar we can get to be able to design for really, really unknowing programmers.

_xtian_

2005-01-11 09:51

reporter   ~0000297

just thinking: additionally to the modifier, that ensures, that compilation is aborted, when a function is overridden without calling the super function, ANOTHER modifier would be useful, that just throws a compilation warning.
This would help for gradually updating big libraries. (where you can't foresee what you'll break)

_xtian_

2005-02-19 14:20

reporter   ~0000330

ideas for names are:
  super, sticky, obligated

zesstra

2008-07-02 03:36

administrator   ~0000657

Mhmm, I like this idea.
But I see a problem here: It is easy to check if the parent the is called at some point, but not easily possible to decide wether this code is executed at all, in some circumstances or if it is guarenteed to be called.
Multiple inheritance complicates it a little as well.

_xtian_

2008-09-27 12:40

reporter   ~0000795

Note that at some point lars suggested the term "required" for this feature, which we all liked best.

_xtian_

2010-03-15 01:14

reporter   ~0001803

Concerning the issue where this could only be properly implemented with a multi-pass interpreter: I would argue that it is sufficient for most cases to only enforce that the first line in the function needs to be ::fun

zesstra

2010-03-15 04:02

administrator   ~0001804

I am not sure about this. I know plenty of functions (including in my own code), which do not call their inherited one at the first line, e.g. because they change an argument before or do whatever else. Some others do something and end with return ::fun();, but there are IMHO enough functions which call the super functions somewhere in between to make this clumsy. (You can't make it an error than und there will be annoying warnings you have to remember to ignore.)

_xtian_

2010-03-15 13:20

reporter   ~0001805

Well, yes, but do they need to get a "required", too?

Most importantly, it'd be an acceptable compromise to get the functionality in ... even if it were just for starters.

Coogan

2010-03-15 17:45

reporter   ~0001806

We use replace_program() with a heuristic approach for a lot of objects. For this purpose, replace_program() must be called earlier then some of the <parent>::super() functions. Thus I can't agree to _xtian_ in #0001803 that the first line should be sufficient in most cases.

Issue History

Date Modified Username Field Change
2004-10-15 21:49 lars New Issue
2004-12-07 06:26 _xtian_ Note Added: 0000239
2005-01-11 09:51 _xtian_ Note Added: 0000297
2005-02-19 14:20 _xtian_ Note Added: 0000330
2008-07-02 03:36 zesstra Note Added: 0000657
2008-09-27 12:40 _xtian_ Note Added: 0000795
2008-12-29 17:35 zesstra Project LDMud => LDMud 3.5
2009-09-26 15:17 zesstra Relationship added related to 0000182
2010-03-15 01:14 _xtian_ Note Added: 0001803
2010-03-15 04:02 zesstra Note Added: 0001804
2010-03-15 13:20 _xtian_ Note Added: 0001805
2010-03-15 17:45 Coogan Note Added: 0001806