object.d and hash_t confusion?

[James Pelcis]

kris wrote:
> James Pelcis wrote:
>> Since the only non-bug problem I noticed here was a programmer error 
>> (using uint instead of hash_t), why should it be changed?
> 
> Well, the hope was that such an easy-to-make 'mistake' would be caught 
> by the compiler :)
Alas, no.  It's similar to (for example) using ubyte instead of GLubyte. 
  Both are legal.  In fact, we don't normally even want the compiler to 
complain about it.

>> If a change does need to be made though, the alias could be changed 
>> into a typedef.  That would check for the problem regardless of the 
>> platform.
> 
> Yep, but probably requires casting. Walter has noted on a number of 
> ocassions that a cast is not exactly intended for general purposes. I 
> just wonder if this should be considered a special-case or not
Casting wouldn't be necessary when using a typedef'ed version of hash_t, 
but it would still be needed whenever it's assigned to a variable. 
Personally, I don't think it's necessary and it definitely isn't 
desirable to need to use casting for the Object class.  I vote to leave 
it as is (with the bug fixed).