[Ohrrpgce] thoughts about slice handles

[Ralph Versteegen]

>> > 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?
>> >
>> > ---
>> > James Paige

2009/1/15 James Paige <Bob at hamsterrepublic.com>:
> Anyway, as I think about this more, I am not sure if I want to take this
> approach or not.
>
> Another option is to just make a couple commands like:
>  create string slice(stringID)
>  update string slice(stringID)
>
(Firstly, a little terminology:
A static string is one accessed with a handle from 0-31, and can be
manipulated with commands like appendascii, inputstring, getheroname,
showstring (see why I put this last one here?)
A plotstring is a string draw to screen, accessed with a handle from
0-31, manipulated with commands like positionstring, stringstyle,
showstringat
Every static string has a corresponding plotstring with the same
handle, which is somewhat inconvenient)

So, you don't want an old style plotstring handle like 31 to be a
valid slice handle, but you want the handle of a string slice to be a
valid static string handle? That seems confused.


I'm uncomfortable with the idea that a string slice handle should also
be a string handle. I don't think that a string slice handle should be
usable to directly access it's string. Instead, why not add a "slice
string" command usable like this (I am jumping ahead and introducing
ideas for a reimplementation of strings as well):

 variable (slice)
 slice := create string slice ("Report")
 #some command that takes a string as argument (we don't actually have any yet)
 Take this to the minister! (slice string(slice))
 slice string(slice) := "Security Report"
 slice string(slice) += " (Classified)"
 set horiz align (slice, edge:center)

(Or maybe some shorter syntax, like 'string(slice)'  where 'string' is
a generic cast command)

Now, back to replacing plotstrings with plotslices.


We have to keep the existing plotstring commands around for
compatibility. I assume you want to reuse them for string slices
(though you create a duplicate of each of them operating on string
slice handles instead and following the same naming scheme as other
slice commands - We already have duplicates of half of them)

Actually, isn't createstringslice redundant to showstringat?
showstringat could be made to take a plotsprite ID, plotslice ID, or
string as first argument.

show string at (ID, x, y)
center string at (ID, x, y)
hide string (ID)
string is visible (ID)
string style (ID, style)
string color (ID, foreground color, background color)
positionstring (ID, x, y)
string X (ID)
string Y (ID)

If you start numbering slices at 10000, and the existing plotstring
commands take either old plotstring handles or new slice handles, that
seems like a good solution. But if the static string splices are each
tied to a static string, would it be most consistent for regular
string slices to also be tieable to string variables?

I'm undecided on references to variables (strings). Basically, I can't
figure out what the result of this code should be:

 variable (a, b)
 a := "A"
 b := a
 b += "B"

For example Euphoria doesn't ever allow two variables to be bound to
the same object (which is restrictive), while in Python assigning
something to a variable binds it to it instead of copying the value
(which causes the complication of mutable vs. immutable objects). But
we could easily support both using different syntax.

We could have it that each string slice either has its own string, or
displays the value stored in a variable.