RFR: 8311895: CSS Transitions [v2]

Michael Strauß mstrauss at openjdk.org
Tue Aug 1 17:11:56 UTC 2023


On Tue, 1 Aug 2023 10:49:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> The constructor ensures that any spelling of "ALL" is converted to the interned constant "all", which is important as we would otherwise need a more computationally expensive case-insensitive string comparison in `Node.Transitions.find()`.
>> Removing the constructor would mean that some unrelated piece of code would need to do this conversion.
>> 
>> The `@throws` tag is not allowed at the class level.
>
> I meant that you can use the short form of the constructor (without repeating the parameters):
> 
>       public record TransitionDefinition(String propertyName, Duration duration,
>                                    Duration delay, Interpolator interpolator) {
>           public TransitionDefinition {  // no parameters necessary (short form constructor)
>                     // do checks and assignments here
>           }
>       }

Done.

>> This algorithm is implemented as [specified](https://www.w3.org/TR/css-easing-1/#step-easing-algo), which accounts for the possibility that the interpolator is used for a back-filling animation (`t < 0`). While this is not possible in JavaFX (but may be possible in the future), I think it makes sense to keep the algorithm as is, because it ensures that its results are always correct, even though negative values for `t` are currently out of spec.
>
> Yeah, I figured as much.  I just don't like code that you can't get covered in a unit test, or that contradicts itself.  As you can see, I was confused, is it a bug or a feature?  Perhaps a comment then to indicate that it's intentional.

This is covered in `StepInterpolatorTest.testStart`: the test will assert that for t<0, the step interpolator produces the expected value. I also added a comment that this is intended.

>> Added a `@throws` tag.
>> Interestingly, `Event` doesn't specify or assert that its `eventType` parameter is non-null. Maybe we should investigate this further.
>
> `eventType` is not used for a lot of things, aside from deciding which list of handlers to pick.  In theory, you could have a `null` `EventType`, and register an event handler on the `null` type; except that most `addEventHandler` methods don't allow this -- they check that the event type is not `null`.
> 
> It probably would be good to reject `null` when creating an `Event`, but that's not for this PR.

I added a null check for `eventType` on the `TransitionEvent` class.

>> Why would this be a sensible thing to do? I'm quite explicitly comparing the identity of `property`, since I'm interested in finding the one property that I'm looking for, not potentially any property that is in some way "equal" to the property.
>> 
>> For (hopefully) all property implementations, `equals` trivially works because it is not an overridden method and therefore falls back to an identity comparison. What would it even mean for a property to be equal, but not identical to another property?
>
> It's up to you, but this is really standard Java practice: you use `equals` which may defer to identity checks, unless there is a very specific reason that you **must** have an identity check.  This leaves the decision of how equality works firmly in the hands of the class author.  
> 
> For styleable properties there may not be an issue, although it is an interface that can have 3rd party implementations. In general though, you never know when something might be a proxy, wrapper or adapter that may not be the exact same instance, but are considered equal for most purposes.
> 
> So if you think it must be an identity check, and you want to avoid others thinking this is a mistake, could you add a comment with the reasoning?

Added a comment.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280922738
PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280919648
PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280921115
PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280921286


More information about the openjfx-dev mailing list