hey Jon, you've opened up another closet full of skeletons :-)
i believe that currently there are several different 'flavors' of NS_NewXXX functions... most/all of the ones being exported from necko act as public helper functions - and are designed to *only* rely on the public necko APIs. at some point, when the necko APIs freeze, we should probably change these functions from being 'exported inline' to just exported 'C' functions... but its easier to leave them the way they are for now... most of the NS_NewXXX functions being exported from layout/content either pre-date our component factory story or are meant to be used 'internally'... i'll defer to the layout group to elaborate on this :-) in the end, you are correct, we need to examine *all* of the exported NS_NewXXX functions and conscious decide which ones are really public, which ones are 'private' but need to be exported for internal consumption and which ones are obsolete and should be removed (or chagned over to use XPCOM component factories...) -- rick Jon Smirl wrote: >Sounds like all of the NS_NewXXX functions need to be carefully inspected to >make sure they only call public APIs. Most of the ones in layout/content >violate this. > >I wish there was a simpler way to separate component public APIs from app >public APIs. Should all app public APIs be required to live in an IDL file? >This would allow the build process to play with the include paths and hide >the non-global component APIs from the rest of the app. > >-- >Jon Smirl >[EMAIL PROTECTED] > > >
