Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of aharui@adobe.com designates
 64.18.1.187 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Tue, 24 Apr 2012 11:00:24 -0700
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
 initializer
Thread-Topic: [jira] [Updated] (FLEX-51) Please check support for ExactValue
 initializer
Thread-Index: Ac0iQmBgRaav+zmkSd+zM+oBTUBw4wAAb7Re
Message-ID: <CBBC3848.3F7B6%aharui@adobe.com>
In-Reply-To: 
 <CAEFz_vuFK_FEUHx6EK7_GXFPEJPXEp0irM2oAn5A+TGYfzQfxQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 4/24/12 10:47 AM, "Omar Gonzalez" <omarg.developer@gmail.com> wrote:

>>=20
>> Optimizing for read-once variable expressions just sounds dangerous to m=
e.
>> I would not want to bake that into the compiler and invite people into a
>> trap.
>>
>=20
> All I'm saying is that if we're going to turn it down it should be on
> technical merit, or lack thereof, as opposed to whether it invites
> something bad, because there's lots of bad things that can be done and if
> we use that as criteria for changes then we'll never make any changes.
I think "technical merit" includes whether a feature has consistent
behavior.  I consider the current binding system to be consistent.  You can
mis-use it, but for any given expression, it will evaluate correctly.  This
proposal, if it includes expressions with variables, introduces timing
dependencies.  I think that is a technical flaw.

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui