View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000136 | LDMud 3.5 | LPC Compiler/Preprocessor | public | 2004-10-15 21:49 | 2010-03-15 17:45 |
Reporter | Assigned To | ||||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | new | Resolution | open | ||
Summary | 0000136: Enforce the call of super functions. | ||||
Description | I 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. | ||||
Tags | No tags attached. | ||||
related to | 0000182 | closed | LDMud | New efun: deep_call_other() |
|
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. |
|
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) |
|
ideas for names are: super, sticky, obligated |
|
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. |
|
Note that at some point lars suggested the term "required" for this feature, which we all liked best. |
|
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 |
|
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.) |
|
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. |
|
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. |
Date Modified | Username | Field | Change |
---|---|---|---|
2004-10-15 21:49 |
|
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 |