[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Improve property system to facilitate correct usage
From:       Michael_Strauß <michaelstrau2 () gmail ! com>
Date:       2021-10-28 16:51:25
Message-ID: CAJEpuXRWcveyfYab3qbN2hUiaeorchyG4HgW0qLT8=Urb74TUw () mail ! gmail ! com
[Download RAW message or body]

I'd like to discuss the API changes surrounding content bindings for
this PR: https://github.com/openjdk/jfx/pull/590

Content bindings in the property system are semantically similar to
regular bindings:
1. You can only have a single content binding for a collection-type property
2. Unidirectional content bindings and bidirectional content bindings
are mutually exclusive

For this reason, and in order to support the behavioral changes
outlined in the PR, the content binding API (in ReadOnlyListProperty)
was changed as follows:

    void bindContent(ObservableList<E> source);
  + @Deprecated(since = "18", forRemoval = true)
    void unbindContent(Object object);
  + void unbindContent();
  + boolean isContentBound();

This is not a breaking change, and allows application developers to
phase out the superfluous argument for `unbindContent` over time.

What might be more controversial is that this imposes a new
implementation requirement for some exotic implementations of
collection-type properties:

1. Right now, content bindings are implemented in
ReadOnlyListProperty, and every implementation of ROLP inherits the
default content binding implementation.

2. With the changed API, the implementation moves from
ReadOnlyListProperty to (ReadOnly)ListPropertyBase. This means that a
class that implements (RO)LP, but not (RO)LPBase, does not inherit the
default content binding implementation and needs to provide its own
implementation if it wants to support content bindings.

Of course, implementing (RO)LP without using (RO)LPBase is extremely
unusual. It requires the implementer to re-implement lots of code like
`ListExpressionHelper` and binding listeners.
Still, it's an additional requirement for these implementations that
also want to support content bindings. If content bindings are not
required, then the "old" (RO)LP implementation will continue to
compile and work.

What we get from this change are powerful correctness guarantees for
users of the API. Do you think this is a trade worth making?


On Wed, Jul 28, 2021 at 1:23 AM Michael Strauß <michaelstrau2@gmail.com> wrote:
>
> I propose a set of changes to the JavaFX property system that I've
> outlined in this PR: https://github.com/openjdk/jfx/pull/590
>
> The changes fall into two categories: enforcement of correct usage
> (there are several cases listed in the PR), and deprecating untyped
> APIs (for removal in a future version) so as to make the intent of the
> API more clear to developers.
>
> Even though there are breaking changes, the impact on application code
> should be minimal. I'd welcome any comments on this proposal.
[prev in list] [next in list] [prev in thread] [next in thread]