[wix-devs] Burn Variable breaking changes

[Sean Hall]

Well, no one has said we definitely shouldn't change the meaning of
"string" so that's what I'll do. I updated the WIP to add "formatted" as a
Variable type and change the signature on SetVariableString.

On Wed, Jul 22, 2020 at 3:07 PM Rob Mensching <rob at firegiant.com> wrote:

> > I think we went with literal in v3 because of the backwards
> compatibility of getting the unescaped value when a BA called
> GetVariableString. I think the convenience of "literal" is worth it, I just
> thought I would mention that we technically could do without it.
>
> That history sounds right. You're closer to the code so I trust your
> judgement call on "literal" vs. doing nothing (except maybe adding a method
> to make it easier to escape strings).
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Friday, July 17, 2020 10:02 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Burn Variable breaking changes
>
> >  SetVariableString(string value, bool formatted);
>
> That seems reasonable.
>
> >  that doesn't change the underlying type (assuming that's a thing)
>
> I don't want that to be a thing. We're designing this where the string is
> declared to be literal or formatted when you're setting the variable. We
> theoretically could have done it differently where you somehow prevented
> the recursion when using the variable but we didn't go that way.
>
> I've been thinking about this literal concept. Everything that you can do
> with literals, you can also do with just escaping the string. I think we
> went with literal in v3 because of the backwards compatibility of getting
> the unescaped value when a BA called GetVariableString. I think the
> convenience of "literal" is worth it, I just thought I would mention that
> we technically could do without it.
>