[DGD]1.1.52

[Frank Schmidt]

On Fri, 5 Mar 1999, Felix A. Croes wrote:

> diff -c dgd/src/Changelog:1.157 dgd/src/Changelog:1.160
> *** dgd/src/Changelog:1.157     Thu Feb 11 15:16:52 1999
> --- dgd/src/Changelog   Fri Mar  5 18:00:22 1999
> ***************
> *** 1224,1226 ****
> --- 1224,1239 ----
>    - Fixed a bug in array exporting, introduced in the last assignment/swapping
>      rewrite.
>    - Fixed the bug in the fix.
> +  - Added the constant `nil'.  If typechecking is 0 or 1 (in the config file),
> +    nil has the value 0.  If typechecking has the value 2, nil is distinct from
> +    integer zero.
> +    String, object, array and mapping variables are initialized to nil.  Using
> +    call_other() to call a non-existant function returns nil.  Variables holdin
> g
> +    an object become nil after the object has been destructed.  Indexing a
> +    mapping with a non-existant index results in nil, and nil must be assigned
> +    to delete an index:value pair; assigning 0 has the same effect only when
> +    0 and nil are the same.

I must congratulate with a very elegant and consistent solution for the
"uninitialized data" problem. This is the nail in the coffin for MudOS
from my point of view. It even brings abit more flexibility (in switch ()
expressions for instance). Very good work!


> +  - allocate() now allocates an array of nil values.  New kfuns allocate_int()
> +    and allocate_float() explicitly allocate arrays of those respective values.

How about defining a kfun (could with advantage be called allocate_array):

 varargs mixed *allocate(int size, mixed value)

instead of having three different functions not really covering all needs
(when you want value different from 0, 0.0 and nil or even an array of
strings!). The function would return an array the size of the first
argument with all elements containing values of the second. The second
argument would default to nil naturally.


> +  - In a further bit of type matching cleanup, integer 0 and floating point 0.0
> +    no longer test as equal.

I do not understand the point of this. Not that I am an expert of ANSI C
standards but shouldn't the lesser operand to ==(,) be automatically
casted to the higher type? So the test of 0.0 == 0 should return !0. This
extends to 1.0 == 1 and all operators, and could be further extended to
LPC: (string)0 and 0, (object)0 and 0... etc.

If you wish to differentiate types, you can always use typeof(). I don't
think the types of the values and variables should interfere with the
logical and mathematical expressions of C.

Maybe I just misunderstood your change...


One backwards compatibility issue. What will happen to:

 object room;
 room = clone_object("/foo/bar");
 destruct_object(room);
 if (!room) ...; /* Will this check be sufficient? */

And will operations with nil result in runtime error (making nil hopeless
to use before you have tested for it), or will nil in some
situations be "casted" to 0:

 nil + 1 /* result of 1 would be nice */
 if (nil == 0) ...; /* will never happen with typechecking = 2? */
 if (!nil) ...; /* should always happen? (logically same as above) */
 if (nil != 0) ...; /* is nill true then? */
 if (nil) ...; /* should never happen? (logically same as above) */

..! Confusing.


I haven't tried out the experimental versions yet, but after 1.1.52 I
think I will (parse_string and private inheritance also looks tempting). 
Great work!

With best regards,

Frank Schmidt.


List config page:  http://list.imaginary.com/mailman/listinfo/dgd