Interesting. I'd never heard of auto-complete as a reason to use ExcludeClass. Size of documentation is a concern, but the main issue, IMO, regarding private, @private, mx_internal and/or ExcludeClass is about backward-compatibility. Once you document it, you can't go changing it without fear of breaking someone's code. So, you'd better be pretty happy with the API names that you want to document, and probably should make sure the API doesn't create a tangled nest of dependencies.
So, I'd argue that you shouldn't remove every ExcludeClass or make every private method public. But if any committer finds something useful and worth documenting, then we should think about the backward-compatibility impact and make the change unless there will be serious repercussions. -Alex On 8/16/14 2:29 PM, "jude" <flexcapaci...@gmail.com> wrote: >For discussion, I think we should remove the [ExcludeClass] from all the >classes in the SDK. The reasons are mainly that I've found really useful >classes usually after the fact that were excluded from auto complete and >documentation. The reasons for ExcludeClass seem to be to make auto >complete faster and remove classes that were deemed not to be important to >developers. I've never had an issue with auto complete being slow and the >last time I was paying attention to what showed in auto complete in AS3 as >I typed was after the first month of use. That is, I don't notice the >classes I'm not looking for as I type but I do notice classes that I find >useful. So if these classes showed up in auto complete it would be *more* >beneficial as I will notice them when I need them and not notice them when >I don't. > >Another reason to remove ExcludeClass is there are cases that these >classes >do not show up in MXML using the mxmlc or in AS3 projects where they will >be used. This causes the compiler to complain and in some cases the app >can't be compiled. Now that everyone agrees we should take a vote.
