Feature Request P2
Status Update
No update yet.
Comments
em...@google.com
Realized this also affects effectively-sealed classes (no public or protected constructors). We should consider adding ClassItem.isEffectivelySealed() to match.
We have three options for the logic:
- Search
Codebasefor all descendent classes of each effectively sealed class and only consider the ancestor class effectively final if all its descendents are concrete or effectively sealed. This matches the behavior inherent to the language. - Disallow sealed (possibly also effectively sealed) classes from having abstract descendents altogether. This limits some potentially valid APIs (E.g.: ADT that the client extends) but might be worth doing if we think this is a bad API pattern.
- Disallow adding abstract methods to any abstract class or interface altogether. This checks is the only exception to rule against adding abstract methods, and maybe it's better to never add abstract methods to existing public classes.
em...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Revert^2 "Add requestFocus(FocusDirection) to focusRequester"
Expand for full commit details
Revert^2 "Add requestFocus(FocusDirection) to focusRequester"
This reverts commit 274c9242bfe89dad5aeb7179750d45fa64c6ab80.
Reason for revert: The original CL was correct. The revert was incorrect.
Relnote: "Adds requestFocus(FocusDirection) to both focusRequester and
FocusTargetModifierNode to allow focusing with a specific
direction."
Bug: 220960090
Test: new test
Change-Id: I96b97720a65d2e1bf8d7f845dc05844f7e7f565c
Files:
- M
compose/ui/ui/api/1.8.0-beta01.txt - M
compose/ui/ui/api/current.ignore - M
compose/ui/ui/api/current.txt - M
compose/ui/ui/api/restricted_1.8.0-beta01.txt - M
compose/ui/ui/api/restricted_current.ignore - M
compose/ui/ui/api/restricted_current.txt - M
compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/focus/ExplicitEnterExitWithCustomFocusEnterExitDemo.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/RequestFocusTest.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusOwnerImpl.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusRequester.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusTargetModifierNode.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusTargetNode.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusTransactions.kt
Hash: fb5d4a3eebdbc0cd3034d11eae8e00f507ec1a68
Date: Wed Nov 06 19:23:12 2024
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: drchen <
Link:
Introduce APIs to support pane preferred heights
Expand for full commit details
Introduce APIs to support pane preferred heights
Note that we need to ignore API checking of adding the modifier
to PaneScaffoldScope, as b/220960090 indicates, the current Metalava
is not able to tell if a sealed interface has been implemented by
an open abstract class. (In our case, all inheritances are sealed or
internal so we are good to ignore the API warning.)
Relnote: "Introduce PaneScaffoldScope.preferredHeight modifier for
devs to provide pane preferred heights that will be applied with
new adapt strategies we are going to introduce."
Test: n/a
Bug: 373490181
Bug: 373489847
Change-Id: I957dd252b2bd154e3b0be048c092147fb6d1b2b8
Files:
- M
compose/material3/adaptive/adaptive-layout/api/current.ignore - M
compose/material3/adaptive/adaptive-layout/api/current.txt - M
compose/material3/adaptive/adaptive-layout/api/restricted_current.ignore - M
compose/material3/adaptive/adaptive-layout/api/restricted_current.txt - M
compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/PaneScaffold.kt - M
compose/material3/adaptive/adaptive-layout/src/commonMain/kotlin/androidx/compose/material3/adaptive/layout/PaneScaffoldDirective.kt
Hash: 0d7a940f0ce81b2a9a699146f48de72a177357b7
Date: Wed Feb 26 11:34:20 2025
Description
Sealed classes and interfaces cannot be extended directly outside their module. Intuitively this implies they are effectively final, and therefore otherwise incompatible changes would be allowed, such as adding a new abstract method.
Unfortunately, it's possible to extend a sealed class with an abstract class as below and inadvertently expose a new abstract method (
funFromSealed()in the example below). We should figure out how we want to model this behavior in Metalava, figure out if there's any other considerations to sealed classes, and then maybe updateClassItem.isEffectivelyFinal()to match.