Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [FlexJS] Bindable and consts
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <D588F0A5.97EF8%aharui@adobe.com>
Date: Mon, 10 Jul 2017 19:22:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <258842C4-6DBC-4F23-9B17-50B600F3489E@gmail.com>
References: <8C4C1CD1-C4D6-404B-9113-520532B44BA9@gmail.com> <DA3ED52B-E06C-4387-9037-7560812BE851@gmail.com> <D588F0A5.97EF8%aharui@adobe.com>
To: dev@flex.apache.org
archived-at: Mon, 10 Jul 2017 16:28:42 -0000

Not urgent right now. Once I figured out what the problem was, I removed =
the Bindable tag. It was not strictly necessary.

In my case the public static const was not exported. Not sure why.

I=E2=80=99m not sure that we always want to export these things either, =
but that=E2=80=99s a whole =E2=80=98nother discussion that I keep =
putting off until we=E2=80=99re in a better place.

Harbs

> On Jul 10, 2017, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID> =
wrote:
>=20
> How urgent is this?  I'm trying to figure out why the compiler did not
> respond properly to bad MXML.
>=20
> I thought public APIs were all exported so they would survive getting
> renamed.  In the minified JS, the code will often access the renamed
> variable, but a tree of objects with properties also gets created.
>=20
> -Alex
>=20
> On 7/10/17, 2:12 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> It appears that this is the case with any public static getter.
>>=20
>> public static function get FOO():String{return =E2=80=9Cfoo=E2=80=9D}
>> or
>> public static function get FOO():Foo{return _foo}
>>=20
>> I don=E2=80=99t see any reason why bracket notation would be needed. =
Is this a
>> throwback from before we had the get__ functions?
>>=20
>> Thanks,
>> Harbs
>>=20
>>> On Jul 9, 2017, at 11:27 PM, Harbs <harbs.lists@gmail.com> wrote:
>>>=20
>>> I just discovered something:
>>>=20
>>> Foo.as:
>>> package com.acme.foobaz.model{
>>> 	[Bindable]public class Foo{
>>> 		static public const BAZ:String =3D =E2=80=9Cbaz=E2=80=9D;
>>> 	}
>>> }
>>>=20
>>> In some other class:
>>>=20
>>> if(baz =3D=3D Foo.BAZ){//do something}
>>>=20
>>> compiles to:
>>> if(baz =3D=3D com.acme.foobaz.model.Foo[=E2=80=9CBAZ=E2=80=9D])
>>>=20
>>> If you remove the [Bindable] meta tag on the Foo class, it compiles =
to:
>>> if(baz =3D=3D com.acme.foobaz.model.Foo.BAZ)
>>>=20
>>> In the debug build, these two are functionally identical. However, =
when
>>> Google minifies the file, it has no way of knowing that Foo.BAZ is =
used.
>>> This results in calling  (assuming com.acme.foobaz.model.Foo becomes =
k)
>>> k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined.
>>>=20
>>> Why does [Bindable] on a class cause the bracket notation to be =
used?
>>>=20
>>> Harbs
>>=20
>=20