On 8/17/14 4:04 PM, "jude" <flexcapaci...@gmail.com> wrote:
>Thanks for the clarification. I forgot about backward compatibility. As >for >code complete, in the Design Extensions Readme Kit.txt I found this >reference: > >PicnicExtensions This part is specific to design extensions. If a TextInput is proxied by a DesignViewTextInput class that is only used to present the TextInput in DesignView and not designed to be used in other applications, I would argue that DesignViewTextInput should have ExcludeClass so it doesn't clutter up the choices in auto-complete. Or, in reality, that the ASDOc and IDEs would allow filtering of classes with particular attributes so you could get documentation on DesignViewTextInput when the time comes to try to fix a bug in it. > > >I don't think that documenting means all these other things. I think once >you know it exists you have the possibility of breaking things when the >class is updated or changed or causing interdependency because for me and >another dev recently are using MediaQueryImporter already all that >ExcludeClass has done was hide it from some highly visible locations. MediaQueryParser is a separate case. Maybe we should add it to the documentation. I think it had ExcludeClass at Adobe because it wasn't really using MediaQuery-compliant CSS tags, so why document it and invite folks to try it only to their disappointment? > > >I'm trying to get a list of classes that have ExcludeClass in them so we >can compare. I know that working on the TLF SDK there were way too many >classes that had ExcludeClass and the compiler would complain until I >removed that tag. I haven't had problems with ExcludeClass and the compiler. Not sure why you are. But again, are you sure you love the APIs in TLF enough to bake more of them "forever"? Like Parcels and all other stuff that was hard to understand? Again, I probably won't veto any individual changes, but I would caution against an automatic removal of all ExcludeClass metadata. -Alex
