Roku Developer Program

[EnTerr]

Disclaimer: question is harder that it looks at first - due to how strings have evolved in BrS. E.g. check if you understand why this is (i just grokked it today... barely):

BrightScript Debugger> a = ["12", "1" + "2"]
BrightScript Debugger> ? type(a[0]), type(a[0], 3)
roString             String
BrightScript Debugger> ? type(a[1]), type(a[1], 3)
String               roString

So my question is, if given a true roString (a mutable object; akin to Java StringBuffer), is there a way for me to get a true String (immutable, intrinsic value; comp. Java String) out of it? Per documentation roString.getString() as String will do that but it doesn't (apparently it's a no-op in BS3).

I have a reason/use-case to look for the roString->String conversion. But I will be perfectly fine if conversion does not exist - just want to check if i missed a function or something; no nudging for a fix.

[dev42]

Why is it that every now and then you throw out what appears to be a simple question that then turns out to be a horrible nightmare?

For the record, I grok nothing! NOTHING!

type(a[0]), type(a[0], 3) = roString            String
type(a[1]), type(a[1], 3) = String              roString

b = toStr(a[0]) : type(b), type(b, 3) = String              String
b = toStr(a[1]) : type(b), type(b, 3) = String              roString

c = String(1, a[0]) : type(c), type(c, 3) = String          roString
c = String(1, a[1]) : type(c), type(c, 3) = String          roString

d = toLeftStr(a[0]) : type(d), type(d, 3) = String          roString
d = toLeftStr(a[1]) : type(d), type(d, 3) = String          roString

the plot thickens!

Edit: forgot to include toStr()

Function toStr(s$) As String
	return s$
End Function

I was hoping "s$" was super magical.

Let me see if I understand what you're asking, you want to be able to create a const string at runtime? ... and what fiendishly clever thing would this be used for?

[EnTerr]

"dev42" wrote:
Why is it that every now and then you throw out what appears to be a simple question that then turns out to be a horrible nightmare?

For the record, I grok nothing! NOTHING! [code] ...

I think i have good understanding what's going on - but it would be better if someone on RokuCo's payroll explains it, for couple of reasons.

I was hoping "s$" was super magical.

Yeah... no. I have seen people using type-suffixes (s$, i#) under the impression/hope that it produces more efficient code. It doesn't. What it does is to perform type check on every assignment to that variable and ensure the value is of the right type.

Let me see if I understand what you're asking, you want to be able to create a const string at runtime? ... and what fiendishly clever thing would this be used for?

Correct. And indeed i have a specific reason to ask - see String de-duper device thread. In short, due to its verbogosity, after parsing an XML source there will be lots and lots of duplicate strings (lots of the same tag names and attribute names) taking up memory - which can be significant if parsing big file on small device. Using the functions from that thread will get rid of duplicates by replacing with references to a single string copy.

But what happens if further in the program you mutate one of the tags names? Then "automagically" all other places referring to that will also have their value changed. Which might be a feature but more often in practice is a bug. If there were a way to convert roString -> String though, i could use said "const strings" in the de-duper and trust a single change won't proliferate. (Because it won't allow calling .SetString() or .AppendString() on that, it'll force you to use `=` which will be a single change)

[RokuKC]

String constants are only created during BrightScript compilation, e.g. from string literals.

There isn't any way to make an roString non-mutable.

In the example of your custom XML parser, if your goal is to avoid copying string data, seems like you might want to make your own string pool object to use for tag and attribute names, but make the API for generating or modifying the XML such that element and attribute additions do the lookup internally so that those strings are re-used. Then I wouldn't expect the client to be able to mutate those strings accidentally unless they went out of their way to do so.

But, unless your XML tag and attribute names are fairly long, I'm not sure if you would be gaining much benefit. Seems to me like the performance cost of using the pool would outweigh the relatively small memory savings in string data.