What is LC's internal text format?
gcanyon at gmail.com
Tue Nov 20 13:31:14 EST 2018
I'll chip in and point out that the implicit conversion caused significant
hiccups in figuring out the offsets issues -- several people (including me)
were fooled by the fact that conversion to UTF-32 results in binary data,
but can be transparently treated as text. Or maybe I'm
mistaken/misremembering, which reinforces the fact that it's confusing. :-)
On Tue, Nov 20, 2018 at 10:25 AM Ben Rubinstein via use-livecode <
use-livecode at lists.runrev.com> wrote:
> This isn't about strongly typed variables though, but about when (correct)
> conversion is possible.
> LC throws an error if you implicitly ask it to convert the wrong kind of
> string to a number - for example, add 45 to "horse". (Obviously
> is fine: the answer would be "45 horses".)
> LC throws an error if you implicitly ask it convert the wrong kind of
> or number to a colour: try setting the backcolor of a control to "horse".
> LC throws an error if asked to convert a number, or the wrong kind of
> to a boolean: try setting the hilite of a button to 45.
> In all these cases, LC knows it cannot do the right thing, so it throws an
> error to tell you so, rather than guessing, for example, what the truth
> of "45" is.
> I'm just suggesting that it cannot know how to correctly convert binary
> into a string - so it should throw an error rather than possibly
> do the wrong thing.
> On 20/11/2018 17:55, Mark Wieder via use-livecode wrote:
> > On 11/20/18 8:33 AM, Ben Rubinstein via use-livecode wrote:
> >> Would it not be better to refuse to make an assumption, i.e. require an
> >> explicit conversion?
> > While I'd love to have the option of strongly typed variables at the
> > level, I know better than to expect that this will ever happen.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode