[Coldstuff] First version of waif-patch

[Matthijs van Duin]

>The architecture for adding waif support that you've used in this 
>patch adds overhead both in terms of memory usage and execution 
>speed for the typical object.  The use of ExtObj isn't something 
>that will work for those reasons.

I actually doubt it will add a significant overhead, if you look at 
the code, dereferencing Obj->ext isn't done that often.. as for 
memory usage, it adds only 4 bytes + overhead of a malloc. I just did 
it because the other options were a *lot* more trouble.


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

That would require me to reallocate the cache spaces all the time. 
Right now I just efree() or EMALLOC() the ext structure whenever 
necessary (when I get a cache holder.. I check whether it's of the 
right type).


>Another might be to look at just having a new thing in the cData 
>union and a separate struct altogether.

That would require me to test for it in almost everything that 
supports both waifs and objs. Worse.. many things currently just use 
an Obj* or objnum. In that case, it'd have to change this all over 
the place to cData. If you're worried about memory and execution 
speed overhead.. this isn't a good idea.


>   There are likely other possibilities.  I'd like to see some 
>discussion of how that will be structured and written (preferably 
>here on this list since I'm not on the Cold Dark a lot of the time 
>that you are due to timezones, etc).



>Also, negative object numbers happen when an object becomes invalid. 
>(So, #2 becomes #-2 if you destroy it.)  So, the changes to how 
>objnums are compared doesn't look correct to me.

I'm fairly sure it can never go wrong, because I only use negative 
obj#s for waifs in places where invalid objects cannot occur.

In places where invalid objects *can* occur, they're in a cData where 
I can check the actual type (WAIF / OBJNUM).


>The things that return ~waif when there is an error should return 
>~type usually.  ~type indicates that something wasn't of the correct 
>~type and is something that code can and should be able to expect.

You don't expect ~type when calling obj.add_method(). I deliberately 
didn't use ~type because WAIFs and OBJs *are* treated as the same 
type in most of the functions. Only very few functions do something 
that you can't do on waifs, so *only* in those cases I throw ~waif 
(for example, del_method() will simply fail with ~methodnf). So using 
~type would actually be inconsistent in those cases.


>Finally, if you're changing the indentation level with a part of 
>your patch, please make sure that you fully correct the indentation 
>level in the surrounding code.

I don't recall having made mistakes on that, where did I go wrong?


>There are various small changes that I have questions about or that 
>looked like they didn't really belong here in this patch. (Due to 
>being entirely unrelated.)  Once we're through some of the 
>structural discussion, and there's a new draft patch, we can return 
>to some of those things.

Yea, in a few places where I can changing code anyway, I couldn't 
resist slightly cleaning them up... stupid of me ofcourse, but hard 
to reverse.


>And in that line of thought ... it'd be easier if, in the future, 
>you provided a short doc explaining the structure of your changes 
>and what some of the intent was as well as the thinking behind the 
>choices made.

Well, most of it is above now :-)

  - xmath

PS could you please send msgs to the list only in the future? I'm 
subscribed in non-digest mode, so I get every message twice if you 
send it both to the list and to me directly


Matthijs van Duin     (NOTE: PGP key has changed!)
- PGP Key: 0x2D6F0BA7   <finger://pgp@hmvd.cds.nl> -
- FP: 205D F7BA FFAD 9070 AB9E  C5A8 BDB0 CA1B 2D6F 0BA7 -