Fair enough.
I guess we should examine how it’s being used. In my app I found 612 cases of
Language.string being used.
I should go though them and catalog when it’s being used.
One that jumped out at me is:
var qString:String = qualifiers.toXMLString();
compiles to:
var /** @type {string} */ qString =
org.apache.royale.utils.Language.string(qualifiers.toXMLString());
qualifiers is of type XML and toXMLString() returns a string.
It looks like almost every case of XML.toXMLString() is being wrapped in
Language.string. That seems like a bug.
> On Nov 14, 2021, at 1:15 AM, Edward Stangler <estang...@bradmark.com> wrote:
>
>
> I think you're right. According to the AVM2 doc (avm2overview.pdf), for
> coerce_s ("Coerce a value to a string"):
>
> "If value is null or undefined, then stringvalue is set to null"
>
> and
>
> "This opcode is very similar to the convert_s opcode. The difference is
> that convert_s will convert a null or undefined value to the string
> "null" or "undefined" whereas coerce_s will convert those values to the
> null value."
>
>
>
> On 11/13/2021 3:49 PM, Greg Dove wrote:
>> I am pretty sure Language.string is behaving correctly.
>>
>> Here's a very simple example of what you get in flash player.
>>
>> var something:* //undefined by default
>>
>> var str1:String = something;
>> var str2:String = something as String;
>> var str3:String = String(something);
>>
>> trace((str1===null),(str2===null),(str3==='undefined'))
>> //true true true
>>
>> here is what the same code compiles to in Royale:
>>
>> var /** @type {*} */ something;
>> var /** @type {string} */ str1 =
>> org.apache.royale.utils.Language.string(something);
>> var /** @type {string} */ str2 =
>> org.apache.royale.utils.Language.as(something,
>> String);
>> var /** @type {string} */ str3 = String(something);
>>
>> And the results, when tested, are the same. Whether or not 'something as
>> String' should be transpiled to Language.string instead of Language.as is
>> 'something' that could perhaps be investigated, but I suspect the explicit
>> use of that is quite rare in code, relative to the implicit coercions that
>> take place.
>>
>>
>>
>>
>> On Sun, Nov 14, 2021 at 8:23 AM Harbs wrote:
>>
>>> Of course and JS works the same way. But Language.string is used for
>>> implicit coercions where it might have an initial value of undefined. In
>>> that case, I don’t think you’d usually want to be using “undefined”. You
>>> probably want “” instead.
>>>
>>> I don’t remember all the discussions we had around this in the past.
>>>
>>> If anyone remembers better, please jog my memory…
>>>
>>> Harbs
>>>
>>>> On Nov 12, 2021, at 8:08 PM, Edward Stangler
>>> wrote:
>>>>
>>>> In Flex, both String(null) == "null" and ""+null == "null" (the string
>>>> "null", not the null value).
>>>>
>>>> Don't know if that's the equivalent of Language.string().
>>>>
>>>>
>>>> On 11/12/2021 4:05 AM, Harbs wrote:
>>>>> I wonder if Language.string() should return “” for undefined. It
>>> currently returns null. I think “” would generally be a more expected
>>> result.
