Open ignas-k opened 3 months ago
The benefits we would receive from this change:
Some ways this change could be achieved:
@internal
it would cause confusion because developers would think these interfaces could be easily modified when in reality it is not the truth. These interfaces would still be 'public' because e.g. FrameworkBackstages
interface is used by a public UiFramework. backstage
property so it cannot be easily modified because it needs to follow support policy. So this solution would not work. We cannot have internal interfaces that are in fact public.@public
but remove them from the barrel file so they won't be exported. This is slightly better as developers would know it is public and could not make breaking changes. However, this method is also questionable because we need to consider whether that would make sense in documentation (having a documented interface that the user cannot access).This change is questionable because of its value, method to correctly implement the change and, in general, does it even make sense not to export interfaces which act as return types for properties, methods. Additionally, this change means we could deprecate all the interfaces that are only used as return types e.g. OpenChildWindowInfo
. To track down and deprecate all of these interfaces would require a lot of time and effort.
Is your feature request related to a problem? Please describe.
As stated here, we have public interfaces which are only used as types for
UiFramework
property types e.g.FrameworkFrontstages
,FrameworkToolSettings
etc. Users have no use for these interfaces because their use is internal.Describe the Solution you'd like
Deprecate public interfaces which are only used as types for
UiFramework
property types e.g.FrameworkFrontstages
,FrameworkToolSettings
etc.