[Coldstuff] First version of waif-patch

[xmath]

First of all: can someone configure this list server to add a 
Reply-To: cold-coldstuff@cold.org header? When I click reply, the 
mail defaults to going to the sender alone, which is usually not the 
intended effect.


>  > In places where invalid objects *can* occur, they're in a cData where
>  > I can check the actual type (WAIF / OBJNUM).
>
>negative object nums can appear in the entire negative numeric range.
>If you had object #14524342 and destroyed it, the objnum would become
>#-14524342, so there are no gaps which can be filled in (cold doesn't
>handle invalid objnums like MOO does).

I know I know, however I've taken care of this:

1. if the data type is available and it's OBJNUM, it's always an 
object number, regardless of its value
2. if the data type is available and it's WAIF, it's always a waif 
(although positive numbers cannot occur in this case)
3. a cObjnum without type indication is an object if it's positive 
and a waif if it's negative. In the places where these are used, a 
negative object number can never occur (except -1), so using that 
number space for waifs is safe.

Examples for (3): the db uses objnums for indexing, and Frame.sender 
is also a cObjnum. In neither case can a negative number ever occur 
(except as waif). Objnums are also passed as parameter to functions 
(in places where invalid object numbers can never occur).

Trust me, it's safe :-)

It's also unavoidable, if I don't do it I'd have to change a LOT of 
things all over the source code. (everywhere where an object is 
identified by cObjnum alone would have to get an extra is_waif flag 
or so).

This is the cleanest way.

(note that outside of the bowels of Genesis, this is never seen. for 
ColdC programmers, a waif is a totally different data type. The fact 
toint(waif) returns a negative number is actually convenient)


>I think the intent Bruce had was to try to not add new error names
>wherever possible, so as to brake as litte existing code as possible.
>If you want it to be synonymous with objects, you may want to throw an
>object error instead of ~waif.

OK, what error should I use? (I really don't like ~type in this 
context, and I'm not familiar enough yet with the whole thing to know 
which errors are appropriate in which context)


>One possibility might be to use structs that have the same layout 
>for the shared portions and then to do some type casting.

I've been thinking about it some more, and on second thought this may 
actually not have the problems I first thought they'd have. I'd only 
have to fiddle a bit in caching (where it must make sure a struct of 
the right size is allocated/deallocated) but other than that there 
should be no problems.

I'll make a new version in the next few days (I'll also pay attention 
not to make any unnecessary changes to the source code - in 
particular no cleaning up)

  - xmath