View Issue Details

IDProjectCategoryView StatusLast Update
0000249LDMudLPC Compiler/Preprocessorpublic2009-10-05 18:31
ReporterlarsAssigned To 
Status closedResolutionwon't fix 
Summary0000249: New datatypes null and error
DescriptionShort: 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.
TagsNo tags attached.
External Data (URL)


related to 0000237 new Possible implementation of T_ERROR 



2009-09-26 18:09

administrator   ~0001297

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.


2009-09-29 11:32

manager   ~0001333

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.


2009-09-30 16:23

administrator   ~0001363

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.


2009-10-01 14:19

reporter   ~0001392

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...


2009-10-01 14:51

manager   ~0001394

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.


2009-10-05 18:31

administrator   ~0001477

I agree with Gnomi and regard the current behaviour as a feature. ;-)
I somebody strongly disagrees, please re-open/leave a note.

Issue History

Date Modified Username Field Change
2004-11-26 23:58 lars New Issue
2004-11-26 23:59 lars Relationship added related to 0000237
2009-09-26 18:09 zesstra Note Added: 0001297
2009-09-29 11:32 Gnomi Note Added: 0001333
2009-09-30 16:23 zesstra Note Added: 0001363
2009-10-01 14:19 Coogan Note Added: 0001392
2009-10-01 14:51 Gnomi Note Added: 0001394
2009-10-05 18:31 zesstra Note Added: 0001477
2009-10-05 18:31 zesstra Status new => closed
2009-10-05 18:31 zesstra Resolution open => won't fix