Hi, mx_internal is a namespace, so it does follow a guideline and that is mx_internal. Adobe has said many times they use this namespace for implementation details that they don't want to expose as a public API.
As far as protected, this again relates to the fact Adobe is building a huge framework that developers subclass. When Adobe puts something in the protected namespace you might as well call it public. Once they assign a protected method it's really been concreted into a API that would be dangerous to change on their part. This has been debated for years and I doubt they will make everything protected. mx_internal is a quasi public interface. Adobe again says, use at your own risk. I think a major part of confusion is languages like Java don't really have namespaces. This is a new way of developing. XML does the same thing in a way. This is for certain though, it dosn't seem like Adobe is going to change their stance on protected and mx_internal, who knows about the opensource inititive though. Just my 2cents and a lot of experience with this debate. PS from my years of developing in this, you might want to bring up design patterns. I have had enough experience with this framework to know it CAN be accessible without making everything 'protected'. That is hella sloppy. One example is how they are changing all managers to an impl where you as the dev can then implement your own based on the established public interface they created. And I know UIComponents could follow the same path in their own respect. Software design is an art, as an artist you constantly remold based on what you see and feel. Mike On Thu, Sep 18, 2008 at 10:47 AM, djhatrick <[EMAIL PROTECTED]> wrote: > I'm wondering, and other people wonder too why even use private > functions in components in flex? How about protected instead? When a > developer is programming these UIComponents, I know it's hard to > understand how your component might be used. But, let's take an > example of the List component. > > Inside List there's a function: > > protected function initiateDataChangeEffect(unscaledWidth:Number, > unscaledHeight:Number) > > The list animations should have been checked against visibleData in > this method, which would prevent animations to occur on items not in > view. Why was this done like this anyway, speed for a release? Who > cares, I need to change it. > > In fact, Alex H maybe, or somebody at Adobe commented in the code: > > // as optimization, we might get targets from visibleData > // if we know that nothing else has changed. > // otherwise, rerender using our preserved collection view > > // store original collection and iterator so we can > // return to using it after the effect has finished > > So here's something we all go through, I want to easily override this > method, but it calls other private methods inside List that I have no > access to override. Developer friendly friends, you are making the > framework for the community, please think about opening up the > internals of the framework. I'm no fan of underclassing, or > rebuilding an entire component to change 3 or 4 methods. I think all > of the components should move to an easier way to override than > currently. Let's get rid of private on all methods and use protected, > at least there's some protection with protected and then our lives > will be easier. > > Also, mx_internal, it seems like a hack, to me. Doesn't seem to me to > follow any sort of guideline? What's the purpose of that > namespace, other than to let me know that these methods may go away. > Who cares, I need to access them anyway, especially in the text > components, since they don't measure properly when nested in complex > layouts. > > Will there be any discussions on the framework plans at AdobeMax? > > Thanks, > Patrick > > > -- Teoti Graphix, LLC http://www.teotigraphix.com Teoti Graphix Blog http://www.blog.teotigraphix.com You can find more by solving the problem then by 'asking the question'.
