View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000303 | LDMud | Efuns | public | 2004-11-27 00:04 | 2022-10-06 20:16 |
| Reporter | Assigned To | Gnomi | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000303: Generic function call operator | ||||
| Description | Short: Generic function call operator From: Lars Date: 2002-09-18 Type: Feature State: New The function call operator() should be implemented as proper operator, so that code as in ' closure cl = ...; cl();' becomes possible (funcall() and apply() would serve the cases where a 'call' of a non-closure should be possible). This would also mean that object->name returns just a lfun-closure. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
This would introduce some ambiguities. Currently variable and functions can have the same name, because the compiler knows, which one to look for: x() // is a function x + 1 // is a variable x->y // is a struct lookup x->y() // is a call_other Although the ambiguities can be resolved by forbidding the same name or making one have preference over the other (e.g. #'x, here x is looked up as a function first, then as a variable), this also means that wizards will face the same ambiguities, i.e. it makes code harder to read. Also it will hide some obvious mistakes: ob->start_program; is now illegal, but will then just produce a closure, but not execute it. On a side node, we would need to have new closure types, because lfun closures would be similar to the call_direct() efun. We would need a new closure type for call_other(), which makes the language more confusing. |
|
|
We wont implemented that due to the reasons described in the previous comment. |
