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 cframpto@adobe.com designates
 64.18.1.35 as permitted sender)
From: Carol Frampton <cframpto@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Wed, 22 Feb 2012 09:04:07 -0800
Subject: Re: [gosh] Compiler choice [was Goshhawk language choices and more]
Thread-Topic: [gosh] Compiler choice [was Goshhawk language choices and more]
Thread-Index: Aczxg/6jt4tWm3zUQBuQ8jxLPsIJ5w==
Message-ID: <CB6A86F9.A194%cframpto@adobe.com>
In-Reply-To: <4F427F9C.4010801@dot-com-it.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>
>
>
>> In my experience, the mx_internal namespace was used often for the
>> purposes such as to cover the weak points in design. I think that the
>> problem of not documenting things could've been solved by @private

At Adobe, every single Flex public property, method and class had to be
approved by the architectual review board which oversees the Flash API.
Once public, it can't be removed from the API since that could break user
code.  From my experience, the tendency of the review board is to keep
things simple and try to maintain consistency across the classes. For
example, an substantial amount of time was spent on property, method and
parameter names.=20

mx_internal was sometimes used by if you thought something should be
public but couldn't justify it to the review board so you left a
back-door.  Sometimes mx_internal was used to cover "weak points in
design".  I think the older code uses mx_internal much more than the newer
code and some engineers use it more than others.

Carol