Open jpobst opened 4 months ago
Regarding Scenario 1, I agree that we should [Obsolete(error:true)]
those types, and remove them in a future release. We should absolutely prefer static members on interfaces, which better mirrors Java.
Regarding Scenario 2, I like having the [Obsolete]
members, as I think they are useful when manually porting Java code to C#, as one may find in e.g. stackoverflow answers. That said, we've stopped emitting these fields for new members ages ago, which means things are now inconsistent. In the interest of consistency, yes, we should also remove these fields as well.
On further sleep & contemplation, one issue with Scenario 1 and removing the "Interface Alternative Classes" is that it'll be an ABI break. Yes, new code can't have been using those types since…(insert date here). However, any assembly built before that day may still be attempting to reference those members, and if a new app uses those older assemblies, then the apps will break.
I can think of only two "workarounds":
internal
. The types will continue to exist, maintaining ABI, while new code won't be able to see the types, cleaning up API.
This issue documents the constructs we have marked as
[Obsolete]
to inform if we want to remove them in the future.Additionally, we would need to decide if any changes are global (affecting both
Mono.Android
and outside users) or if we will feature flag them and whether the flag will be opt-in or opt-out.Scenario 1 - Interface Alternative Classes
When C# 8 added support for
static interface
members, matching Java's support, it removed the need for many workarounds we had previously employed to make these members available. Previously, we had copied thesestatic
members to a similarly namedclass
. As of API-30, we place thestatic
members in their originalinterface
and mark these "alternative" classes as[Obsolete]
.Example:
As of API-35 there are 179 of these "alternative" classes.
Possible next deprecation step(s):
[Obsolete ("...", error: true)]
Scenario 2 - Enumified Constants
When we create an
enum
from a set of constants as part of enumification, we use to leave the constant in its original location. At some point we decided this was confusing, and as of API-30 we mark these original locations with[Obsolete ("...", error: true)]
.Example:
As of API-35 there are 7501 instances of these
[Obsolete ("...", error: true)]
constants.Possible next deprecation step(s):
Scenario 3 - Interface Consts Alternative Classes
Before we created scenario 1, we originally moved interface constants to an alternative
type
with aConsts
suffix where they could be accessed.Example:
This alternative class is always
error: true
, and is not generated at all if C# 8's interface constants feature is turned on. (lang-features=interface-constants
)As
Mono.Android
usesinterface-constants
, there are 0 of these types in API-35.