Roku Developer Program

[EnTerr]

Reading doco:

"3.2 Types" wrote:
... Internally there are two intrinsic string states. The first is for constant strings. For example, s="astring", will create an intrinsic constant string. But once a string is used in an expression, it becomes an "roString". For example: s=s+"more", results in s becoming an "roString".

That does not seem to be the case though:

BrightScript Debugger> s="astring"
BrightScript Debugger> ? type(s)
String
BrightScript Debugger> s=s+"more"
BrightScript Debugger> ? type(s)
String

The result was String again. Yet roString exists:

BrightScript Debugger> ss = createobject("roString") 
BrightScript Debugger> ? type(ss)
roString
BrightScript Debugger> ss.setString(s)
BrightScript Debugger> ? ss
astringmore
BrightScript Debugger> ? type(ss)
roString

Is documentation wrong? What's the relation between the two?

[NewManLiving]

If my memory serves me correctly it may have something to do with
Wrapping or boxing of the intrinsic types with their
Object wrappers. Esp when sending intrinsic
To functions. I believe there is something in the docs under wrappers

[TheEndless]

Not an answer to your question, but kind of on-topic... I've found explicitly creating an roString allows you to update multiple objects with a single call. For example:

titleString = CreateObject("roString")
titleString.SetString("Title")
object1 = {
    Title: titleString
}
object2 = {
    Title: titleString
}
titleString.SetString("NewTitle")

This will update the Title attribute on both object1 and object2. I find it particularly useful when maintaining the same data on multiple layers of an image canvas or roScreen (e.g., for button focus states).

[RokuMarkn]

That makes sense. roString is an object, and like all objects, assignment just copies a pointer to the object. String is a literal, so copying one copies its contents, like copying an integer copies its contents. I certainly agree, it's not always easy to see when a variable contains a String or an roString. There is a sense in which what the doc says is true, Strings are converted to roStrings when necessary, but it's not always easy to predict when it's necessary. It's best to explicitly convert to roString if you need an object.

--Mark

[EnTerr]

"RokuMarkn" wrote:
I certainly agree, it's not always easy to see when a variable contains a String or an roString. There is a sense in which what the doc says is true, Strings are converted to roStrings when necessary, but it's not always easy to predict when it's necessary. It's best to explicitly convert to roString if you need an object.

Well, when in doubt we can always check with `type()`, right? How come the example above, taken literally from the RTFM does not work?! It should have returned "roString" and it didn't.

Something sinister seems to happen though:

BrightScript Debugger> s = "foo": ?type(s),s, : s.setString("bar"): ?type(s),s     '#1
String           foo             String          foo
BrightScript Debugger> s = "f"+"oo": ?type(s),s, : s.setString("bar"): ?type(s),s   '#2
String foo             String          bar
BrightScript Debugger> s= ["foo"][0]: ?type(s),s, : s.setString("bar"): ?type(s),s   '#3
roString               foo             roString        foo

One of those things is not like the other. Actually none are like the other, this is utterly befuddling! First, we see that sometimes mutator setString() does not change String (#1, as expected) - and sometimes it does (#2, wha?). And second, it does not change roString, which it should (#3, military grade "wtf?")

I was thinking boxed values can be used - after theEndless example - for passing function params "by reference" but now don't know what to think, massaraksh.