incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: [gosh] Compiler choice [was Goshhawk language choices and more]
Date Wed, 22 Feb 2012 18:18:17 GMT
> At Adobe, every single Flex public property, method and class had to be approved by the
architectual review board which oversees the Flash API.

This is also true of 'protected' ones.

- Gordon Smith, Adobe (member of the Platform Architectural Review Board)


-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com] 
Sent: Wednesday, February 22, 2012 9:04 AM
To: flex-dev@incubator.apache.org
Subject: Re: [gosh] Compiler choice [was Goshhawk language choices and more]

>
>
>
>> 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. 

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


Mime
View raw message