Creating Clearer Method Names & Concepts
phidias51 at gmail.com
Fri Nov 2 11:38:10 PDT 2012
And the second part of that first question is "how it will play with the
validation framework"? If I'm creating a text field bound to a
SimpleTextProperty and the user enters a semantically invalid value into
the field (i.e. they stuck the contents of the great American novel into a
120 char field), what should I listen for? Am I going to have an
"validation" property as well as a "invalidation" property? Perhaps
EagerChangeListener and LazyChangeListener, or
Optimistic/PessimisticChangeListener would be clearer?
I know it's probably in people's noise level at this point, but the
semantics behind the names of things often make all the difference when
you're trying to figure things out.
On Fri, Nov 2, 2012 at 11:28 AM, Richard Bair <richard.bair at oracle.com>wrote:
> That is correct. Essentially, the property is not invalid when it changes,
> only when it *might* have changed (since determining the value of the
> binding might require the resolution of some arbitrarily complicated graph
> of bindings, and would therefore be expensive to do eagerly). It means,
> that the value is unknown and requires recomputation.
> An InvalidationListener therefore is notified whenever a property becomes
> invalid, vs when we know the value has actually changed.
> I believe that when a ChangeListener is installed, we will figure out
> whether the thing has changed immediately (making it eager) and send
> I tend to always use Invalidation listeners because the method signature
> is shorter ;-). Also, unless I explicitly read the value in the listener, I
> won't cause it to be recomputed (but if I do read it in the listener, then
> of course that is what I wanted to do, so no harm done).
> I can't vouch for the names on the Axis, I don't remember those.
> On Nov 2, 2012, at 11:20 AM, Tom Eugelink <tbee at tbee.org> wrote:
> > Oh! Let me try to explain that (and see if I got it right).
> > The bind is lazy, so when a property changes all bound properties are
> made invalid (this is when the Invalidation event is fired), but they are
> not recalculated. Only when the getter is executed, that property really is
> recalculated (with all kinds of performance cascading things going on) and
> then new value is known (this is when the Changed event is fired).
> > Have I got it right?
> > Tom
> > On 2012-11-02 19:14, Mark Fortner wrote:
> >> I still find myself tripping over the names of methods or concepts in
> >> JavaFX API -- where the API says "X", but only after you dig into the
> >> documentation do you discover that it really means Y.
> >> For example, property "Invalidation" doesn't really communicate what the
> >> code is actually doing. The property isn't invalid, it's value has
> >> been validated (we don't yet have that concept in the API), so how can
> >> property be "invalid"? All that's really indicated is that the property
> >> value has been changed -- although the subtle distinction between
> >> InvalidationListener and ChangeListener is lost on me and I always use a
> >> ChangeListener.
> >> At some point when we have a validation framework for JavaFX, how will
> >> concomitant method calls that come with that framework, play out with
> >> existing method calls. There will probably be a lot of head scratching
> >> going on.
> >> And there's the documentation for *Axis.toNumericValue*, and *
> >> Axis.toRealValue*:
> >> Granted, "All axis values must be representable by some numeric value."
> >> what I really want to know is are we translating from user space
> >> coordinates to data space coordinates? Or vice-versa? What is a "real
> >> value" and what is a "numeric value"? Aren't all values in an XY chart
> >> numbers?
> >> And why is that if I'm translating from user space to data space that I
> >> still need to take into account the width of the Y-Axis? Shouldn't I be
> >> able to get coordinates relative to the chart's content space?
> >> Cheers,
> >> Mark
More information about the openjfx-dev