View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000249 | LDMud | LPC Compiler/Preprocessor | public | 2004-11-26 22:58 | 2009-10-05 16:31 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000249: New datatypes null and error | ||||
| Description | Short: New datatypes NULL and ERROR From: Lars Date: 2001-06-03 Type: Feature State: New Introduce a new value/type 'null' which is to be used for ie. destructed objects and such. It could have a string attribute denoting how the 'null' was created ("constant", "destructed object"). This would be an incompatible change, as 'if (ob == 0) { ob destructed }' would no longer be valid. Introduce a new value/type 'error' which behaves a bit like 'null', but is returned in case of errors. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
| related to | 0000237 | new | Possible implementation of T_ERROR |
|
|
I believe that change requires, that all mudlibs have to be rewritten. Not only the core libs, but also most of the code from individual wizards. While we might make this optional, I am very sceptical, that there are many muds starting up right now and I can't imagine any of the established muds would be willing or able to do this. |
|
|
I'm not that afraid of some rewrites (the compiler would complain and evaluation in a boolean context (like if(ob)) will still work, comparison with 0 could also be made possible). But I'm not convinced of the benefit such an additional type would bring. |
|
|
Mhmm, ok, I had Lars 'if (ob == 0) { ob destructed }' in mind. That is really the main problem. But I think, Lars wanted deliberately, that this comparison is not any more true and that you have to check for destructed objects by comparing with null to remove the multiple semantics of the numerical 0. BTW: the compailer won't complain with mixed (and weak_types, I guess). While I agree, you should not use too many of that, we have plenty of that in old code. So... Right know I oppose that datatype. Concerning the dedicated type for errors: I think that is more interesting and would also avoid using 0 for different semantic things. But to introduce it consistently we have to add to a lot of places. And checking it mudlib-wide is also a lot to do. |
|
|
What about throwing an error for comparision between incompatible types, e.g. object and int (at least in strong_types or strict_types mode)? To check if an object is destructed sth. like 'if (destructp(ob))' could replace the check type 'if (ob==0)'. In my (naive) opinion it takes an internal flag if the object ob has been destructed to distinguish between an integer-0 and an nullified destructed object. As a coder, I can check the type of almost everything -- int, array, mapping, string, object, struct, closure. For all those we can check the size, length and so on. Only for objects we can't test if the object was not initialised yet or is destructed. Adding a destructp() that gap (for objects) could be closed. Maybe there are more of these points I don't see right now. I don't say it's practical, these are only my 2 cents... |
|
|
There's more to the multiple semantics of the numerical 0 than just destructed objects. All uninitialized variables get that. So would they also get null instead (or if not - get the empty string/mapping/array)? The behavior of pointers to destructed objects is now that they just vanish. In mappings their entry is removed, their variables will get uninitialized again. So there's nothing left to check. It took a while to get there (a while ago there were error messages when calling closures of destructed objects) and I'd rather like to keep the current behavior. I think it's a very nice feature, that destruct(ob) kills the object and removes all its traces. |
|
|
I agree with Gnomi and regard the current behaviour as a feature. ;-) I somebody strongly disagrees, please re-open/leave a note. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 22:58 |
|
New Issue | |
| 2004-11-26 22:59 |
|
Relationship added | related to 0000237 |
| 2009-09-26 16:09 | zesstra | Note Added: 0001297 | |
| 2009-09-29 09:32 | Gnomi | Note Added: 0001333 | |
| 2009-09-30 14:23 | zesstra | Note Added: 0001363 | |
| 2009-10-01 12:19 | Coogan | Note Added: 0001392 | |
| 2009-10-01 12:51 | Gnomi | Note Added: 0001394 | |
| 2009-10-05 16:31 | zesstra | Note Added: 0001477 | |
| 2009-10-05 16:31 | zesstra | Status | new => closed |
| 2009-10-05 16:31 | zesstra | Resolution | open => won't fix |
