At 9:06 PM -0500 2/2/02, Scott A Crosby wrote:
>  >
>>  This second class of usage is the primary motivation for adding the
>>  header bit. All the alternatives to this that I've seen either
>>  severely limit the functionality or are extremely ugly.
>>
>
>Do you really need a header bit? What about just reserving a seperate
>range of memory for such objects, then, you just see if its in that range
>before deciding whether or not to allow the mutation.

This would be of some use, and is a conceivable compromise 
implementation. However, I need to be able to toggle a given object 
in and out of this state fairly frequently, and that gets more 
complicated and less performant with a separate memory area.

Also, when objects are created I can't always tell whether they 
should go in the separate memory area or not, and that complicates 
things further.

>
>There are also issues of what about:
>
>    foo array mutate
>    foo mutate

Sorry, but I don't understand the question here. Explain further?

>
>
>>  So I still think the proposal to be worth seriously considering.
>>
>
>Can you explain how, where, and why you need these bits? There doesn't
>seem room to get them..

I haven't seen the other proposals for changing the header, so I 
can't yet say where the bit (I only need one) would come from.

>
>Also, I would be careful about considering removing hashBits. Take away
>just two hashbits, and Morph becomes at least twice as slow, or even
>1000x.

Agreed, removing hash bits is not desirable.

-Martin