[Ohrrpgce] thoughts about slice handles

[James Paige]

On Tue, Jan 20, 2009 at 08:23:13PM +1300, Ralph Versteegen 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?
> >> >
> >> > ---
> >> > 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.

Okay, what I will do first for plotstrings is to convert their internal 
representation to slices without making any changes whatsoever in the 
plotscripting interface.

I'll worry about the next step after that.

---
James Paige