[Ohrrpgce] thoughts about slice handles

[Mike Caron]

S'orlok Reaves wrote:
> Given my limited knowledge of how the Standard OHR actually works, this still seems to handle things well. My main question is: what takes up slots 32 to 99999? I don't like the idea of excessive wasted space, unless it's unavoidable. 

If I understand correctly, my top-posting friend, then the only space 
"wasted" is address space. I.e., slice IDs < 100000 don't exist. They're 
virtual IDs that point into the physical slice table (which starts at 
one, and works its way up).

I suppose we could create other virtual mappings, via constants, to 
other special slices, such as the screen, or whatever.

> --- On Wed, 1/14/09, James Paige <Bob at HamsterRepublic.com> wrote:
> 
>> From: James Paige <Bob at HamsterRepublic.com>
>> Subject: [Ohrrpgce] thoughts about slice handles
>> To: ohrrpgce at lists.motherhamster.org
>> Date: Wednesday, January 14, 2009, 1:12 PM
>> So I am thinking about slice handles.
>>
>> As I have implemented them so far, slice handles are >0
>> indexes into the 
>> plotslices() array.
>>
>> I was thinking about the conversion of floating plotstrings
>> to string 
>> slices. String handles are currently static numbers from
>> 0-31
>>
>> What if I make it so that slice handles start at some
>> higher number like 
>> say 100000. now, slice handle 100000 would actually be
>> plotslices(0) and 
>> 100001 would be plotslices(1)
>>
>> So suppose you pass a static string handle of 31 to
>> "append ascii"
>>
>> That slice handle would be pulled from a static unfreeable
>> list of 
>> string slice handles created when the program starts.
>>
>> But if you pass 100004 which happens to be the return
>> result of "new 
>> string slice" as the handle for "append
>> ascii", then it will know to 
>> pull that string slice handle from plotslices(4).
>>
>> Even though plotslices() and staticstringslices() would be
>> separate 
>> tables, they would still be populated with pointers to
>> slices in the 
>> same slice tree, so old static strings would be fully
>> interchangeable 
>> with other slices for string operation purposes.
>>
>> That would NOT give you the ability to use old static
>> string handles for 
>> things like anchor & alignment changes or
>> tree-heirachy-relocation, but 
>> that would be okay.
>>
>> The same approach could be used later also for other
>> handles that get 
>> converted into slices (for example, maybe custom menu
>> handles).
>>
>> This seems like the best approach to enable slices while
>> maintaining 
>> backwards compatability with existing code, and with the
>> right wrapper 
>> functions it would not be to rough to code.
>>
>> Any thoughts?
>>

-- 
Mike