Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32467 > unrolled thread

Re: Self-updating relationship

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-02 17:14 -0400
    Re: Self-updating relationship Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-02 17:46 -0400
      Re: Self-updating relationship Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 21:06 -0400
        Re: Self-updating relationship e.d.programmer@gmail.com - 2015-09-04 04:46 -0700
          Re: Self-updating relationship Arne Vajhøj <arne@vajhoej.dk> - 2015-09-04 19:43 -0400
      Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-04 11:49 -0400
        Re: Self-updating relationship Arne Vajhøj <arne@vajhoej.dk> - 2015-09-04 19:45 -0400
          Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-04 22:10 -0400
            Re: Self-updating relationship Arne Vajhøj <arne@vajhoej.dk> - 2015-09-04 22:31 -0400
              Re: Self-updating relationship Arne Vajhøj <arne@vajhoej.dk> - 2015-09-04 22:38 -0400
              Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-04 22:51 -0400
    Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-02 18:49 -0400
      Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-02 19:28 -0400
        Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-02 23:52 -0400
          Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 10:32 -0400
            Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-03 10:53 -0400
              Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 11:31 -0400
                Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 11:35 -0400
                Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 11:49 -0400
                Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-03 12:16 -0400
                  Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 13:03 -0400
            Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 10:55 -0400
        Re: Self-updating relationship James Kuyper <jameskuyper@verizon.net> - 2015-09-03 00:06 -0400
      Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-02 23:38 -0400
        Re: Self-updating relationship Jeff Higgins <jeff@invalid.invalid> - 2015-09-03 01:22 -0400

Page 1 of 2  [1] 2  Next page →

#32467 — Re: Self-updating relationship

On 09/02/2015 04:18 PM, Stefan Ram wrote:
> Newsgroups: comp.lang.c,comp.lang.java.programmer
> 
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> the programmer. In this case, it was this comment that led me to realise 
>> that the OP was interpreting his "spaces = height - number;" statement 
>> as defining some kind of self-updating relationship (like a spreadsheet 
>> formula).
> 
>   FWIW, in Java, one /can/ program in this way.
> 
> public final class Main
> { public static void main( final java.lang.String[] args )
>   {
> 
>     final javafx.beans.property.IntegerProperty height
>     = new javafx.beans.property.SimpleIntegerProperty( 10 );
> 
>     final javafx.beans.property.IntegerProperty number
>     = new javafx.beans.property.SimpleIntegerProperty(  2 );
> 
>     final javafx.beans.binding.NumberBinding spaces =
>     height.subtract( number );
> 
>     java.lang.System.out.println( spaces.getValue() );
> 
>     height.set( 20 );
> 
>     java.lang.System.out.println( spaces.getValue() ); }} /* prints:
> 
> 8
> 18                                                         */

What's the java feature that makes "spaces" above update automatically?
To put it another way - if I didn't want such updates, what should I
write differently?

[toc] | [next] | [standalone]

#32469

On 9/2/2015 5:25 PM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>>> final javafx.beans.property.IntegerProperty height
>>> = new javafx.beans.property.SimpleIntegerProperty( 10 );
>>> final javafx.beans.property.IntegerProperty number
>>> = new javafx.beans.property.SimpleIntegerProperty(  2 );
>>> final javafx.beans.binding.NumberBinding spaces =
>>> height.subtract( number );
>>> java.lang.System.out.println( spaces.getValue() );
>>> height.set( 20 );
>>> java.lang.System.out.println( spaces.getValue() ); }}
>> What's the java feature that makes "spaces" above update automatically?
>> To put it another way - if I didn't want such updates, what should I
>> write differently?
>
>    This depends on the details of the behavior you want instead.
>    For one example, you can simply omit »height.set( 20 )«, and
>    »spaces« will not be updated. Or, you could just write:
>
> public final class Main
> { public static void main( final java.lang.String[] args )
>    { final javafx.beans.property.IntegerProperty spaces
>      = new javafx.beans.property.SimpleIntegerProperty( 8 );
>      java.lang.System.out.println( spaces.getValue() ); }}
>
>    Which just will print »8« and not update spaces, or just
>
> public final class Main
> { public static void main( final java.lang.String[] args )
>    { int const spaces = 8; java.lang.System.out.println( spaces ); }}
>
>    or just,
>
> public final class Main
> { public static void main( final java.lang.String[] args )
>    { java.lang.System.out.println( 8 ); }}
>
>    to get the same behavior.

     It's worth noting that the javafx package is not part of "core
Java" (more formally, "Java SE"), but is an optional add-on called
JavaFX.  (JavaFX is well-known as the technology that has made all
of AWT, Swing, SWT, Flash, and HTML5 obsolete. :)

     In other words, the machinery that makes the updates happen is
not "a Java feature" any more than GMP is "a C feature."

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32511

On 9/2/2015 5:46 PM, Eric Sosman wrote:
>      It's worth noting that the javafx package is not part of "core
> Java" (more formally, "Java SE"), but is an optional add-on called
> JavaFX.  (JavaFX is well-known as the technology that has made all
> of AWT, Swing, SWT, Flash, and HTML5 obsolete. :)
>
>      In other words, the machinery that makes the updates happen is
> not "a Java feature" any more than GMP is "a C feature."

JavaFX is not part of Java SE.

But it is not just any library.

* it is created by the caretaker (or whatever we want to call
   Oracle) of Java SE
* it is intended to replace a part of Java SE
* it is bundled with the reference implementation of Java SE

Arne

[toc] | [prev] | [next] | [standalone]

#32517

On Thursday, September 3, 2015 at 9:07:22 PM UTC-4, Arne Vajhøj wrote:
> JavaFX is not part of Java SE.
> 
> But it is not just any library.
> 
> * it is created by the caretaker (or whatever we want to call
>    Oracle) of Java SE
> * it is intended to replace a part of Java SE
> * it is bundled with the reference implementation of Java SE
> 
> Arne

It is a separate jar but it is now installed with JavaSE 8.

[toc] | [prev] | [next] | [standalone]

#32532

On 9/4/2015 7:46 AM, e.d.programmer@gmail.com wrote:
> On Thursday, September 3, 2015 at 9:07:22 PM UTC-4, Arne Vajhøj wrote:
>> JavaFX is not part of Java SE.
>>
>> But it is not just any library.
>>
>> * it is created by the caretaker (or whatever we want to call
>>     Oracle) of Java SE
>> * it is intended to replace a part of Java SE
>> * it is bundled with the reference implementation of Java SE
>
> It is a separate jar but it is now installed with JavaSE 8.

As I wrote then it is bundled with the reference implementation
of Java SE (Oracle Java).

And in fact it has been so since 7 update something.

But if you pick another Java implementation like
IBM Java, then it is not there.

Arne

[toc] | [prev] | [next] | [standalone]

#32525

On 09/02/2015 05:46 PM, Eric Sosman wrote:
>
>      It's worth noting that the javafx package is not part of "core
> Java" (more formally, "Java SE"), but is an optional add-on called
> JavaFX.  (JavaFX is well-known as the technology that has made all
> of AWT, Swing, SWT, Flash, and HTML5 obsolete. :)
>
>      In other words, the machinery that makes the updates happen is
> not "a Java feature" any more than GMP is "a C feature."
>
Another note of interest:
 From the "Oracle Java SE and Oracle Java Embedded Products" page
<http://www.oracle.com/technetwork/java/javase/terms/products/index.html>

Java SE includes:

   The Java Development Kit (JDK),
     including the JavaFX Software Development Kit (SDK),

   Java Runtime Environment (JRE),
     (Server and regular packages)

   JavaFX Runtime,

   JRockit JDK

The javafx package is not part of the Java Development Kit (JDK).

You're allowed limit your "core Java" to the
packages available within the JDK, if you like
but you cannot exclude the javafx packages from "Java SE".

[toc] | [prev] | [next] | [standalone]

#32533

On 9/4/2015 11:49 AM, Jeff Higgins wrote:
> On 09/02/2015 05:46 PM, Eric Sosman wrote:
>>
>>      It's worth noting that the javafx package is not part of "core
>> Java" (more formally, "Java SE"), but is an optional add-on called
>> JavaFX.  (JavaFX is well-known as the technology that has made all
>> of AWT, Swing, SWT, Flash, and HTML5 obsolete. :)
>>
>>      In other words, the machinery that makes the updates happen is
>> not "a Java feature" any more than GMP is "a C feature."
>>
> Another note of interest:
>  From the "Oracle Java SE and Oracle Java Embedded Products" page
> <http://www.oracle.com/technetwork/java/javase/terms/products/index.html>
>
> Java SE includes:
>
>    The Java Development Kit (JDK),
>      including the JavaFX Software Development Kit (SDK),
>
>    Java Runtime Environment (JRE),
>      (Server and regular packages)
>
>    JavaFX Runtime,
>
>    JRockit JDK
>
> The javafx package is not part of the Java Development Kit (JDK).
>
> You're allowed limit your "core Java" to the
> packages available within the JDK, if you like
> but you cannot exclude the javafx packages from "Java SE".

We sure can.

A Java implementation can be fully Java SE compliant without
JavaFX.

And I think that in fact most Java 8 implementations besides
reference implementation (Oracle) comes without. IBM certainly does.

The above page is about "Java SE product". Java SE is a
specification not a product. Oracle Java SE is a product and
that does indeed contain JavaFX.

Arne

[toc] | [prev] | [next] | [standalone]

#32534

On 09/04/2015 07:45 PM, Arne Vajhøj wrote:
> On 9/4/2015 11:49 AM, Jeff Higgins wrote:
>> On 09/02/2015 05:46 PM, Eric Sosman wrote:
>>>
>>>      It's worth noting that the javafx package is not part of "core
>>> Java" (more formally, "Java SE"), but is an optional add-on called
>>> JavaFX.  (JavaFX is well-known as the technology that has made all
>>> of AWT, Swing, SWT, Flash, and HTML5 obsolete. :)
>>>
>>>      In other words, the machinery that makes the updates happen is
>>> not "a Java feature" any more than GMP is "a C feature."
>>>
>> Another note of interest:
>>  From the "Oracle Java SE and Oracle Java Embedded Products" page
>> <http://www.oracle.com/technetwork/java/javase/terms/products/index.html>
>>
>> Java SE includes:
>>
>>    The Java Development Kit (JDK),
>>      including the JavaFX Software Development Kit (SDK),
>>
>>    Java Runtime Environment (JRE),
>>      (Server and regular packages)
>>
>>    JavaFX Runtime,
>>
>>    JRockit JDK
>>
>> The javafx package is not part of the Java Development Kit (JDK).
>>
>> You're allowed limit your "core Java" to the
>> packages available within the JDK, if you like
>> but you cannot exclude the javafx packages from "Java SE".
>
> We sure can.
>
> A Java implementation can be fully Java SE compliant without
> JavaFX.
>
> And I think that in fact most Java 8 implementations besides
> reference implementation (Oracle) comes without. IBM certainly does.
>
> The above page is about "Java SE product". Java SE is a
> specification not a product. Oracle Java SE is a product and
> that does indeed contain JavaFX.
>

Please point me to the Java SE specification.

[toc] | [prev] | [next] | [standalone]

#32535

On 9/4/2015 10:10 PM, Jeff Higgins wrote:
> On 09/04/2015 07:45 PM, Arne Vajhøj wrote:
>> On 9/4/2015 11:49 AM, Jeff Higgins wrote:
>>> You're allowed limit your "core Java" to the
>>> packages available within the JDK, if you like
>>> but you cannot exclude the javafx packages from "Java SE".
>>
>> We sure can.
>>
>> A Java implementation can be fully Java SE compliant without
>> JavaFX.
>>
>> And I think that in fact most Java 8 implementations besides
>> reference implementation (Oracle) comes without. IBM certainly does.
>>
>> The above page is about "Java SE product". Java SE is a
>> specification not a product. Oracle Java SE is a product and
>> that does indeed contain JavaFX.
>
> Please point me to the Java SE specification.

Language:

https://docs.oracle.com/javase/specs/jls/se8/html/index.html

VM:

https://docs.oracle.com/javase/specs/jvms/se8/html/index.html

API:

http://docs.oracle.com/javase/8/docs/api/

Yes - you usually don't think about the latter as a specification.

But read what it says.

"This document is the API specification for the Java™ Platform, Standard 
Edition."

And JavaFX is not included.

Arne

[toc] | [prev] | [next] | [standalone]

#32536

On 9/4/2015 10:31 PM, Arne Vajhøj wrote:
> On 9/4/2015 10:10 PM, Jeff Higgins wrote:
>> On 09/04/2015 07:45 PM, Arne Vajhøj wrote:
>>> On 9/4/2015 11:49 AM, Jeff Higgins wrote:
>>>> You're allowed limit your "core Java" to the
>>>> packages available within the JDK, if you like
>>>> but you cannot exclude the javafx packages from "Java SE".
>>>
>>> We sure can.
>>>
>>> A Java implementation can be fully Java SE compliant without
>>> JavaFX.
>>>
>>> And I think that in fact most Java 8 implementations besides
>>> reference implementation (Oracle) comes without. IBM certainly does.
>>>
>>> The above page is about "Java SE product". Java SE is a
>>> specification not a product. Oracle Java SE is a product and
>>> that does indeed contain JavaFX.
>>
>> Please point me to the Java SE specification.
>
> Language:
>
> https://docs.oracle.com/javase/specs/jls/se8/html/index.html
>
> VM:
>
> https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
>
> API:
>
> http://docs.oracle.com/javase/8/docs/api/
>
> Yes - you usually don't think about the latter as a specification.
>
> But read what it says.
>
> "This document is the API specification for the Java™ Platform, Standard
> Edition."
>
> And JavaFX is not included.

Maybe also relevant is that there is a JCK aka Java TCK
where you need to pass the tests (10 years ago it was
supposedly 70000 unit tests) before you are allowed
to call something Java.

(and IBM Java must have passed - and they sure don't have JavaFX)

Arne

[toc] | [prev] | [next] | [standalone]

#32537

On 09/04/2015 10:31 PM, Arne Vajhøj wrote:
> On 9/4/2015 10:10 PM, Jeff Higgins wrote:
>> On 09/04/2015 07:45 PM, Arne Vajhøj wrote:
>>> On 9/4/2015 11:49 AM, Jeff Higgins wrote:
>>>> You're allowed limit your "core Java" to the
>>>> packages available within the JDK, if you like
>>>> but you cannot exclude the javafx packages from "Java SE".
>>>
>>> We sure can.
>>>
>>> A Java implementation can be fully Java SE compliant without
>>> JavaFX.
>>>
>>> And I think that in fact most Java 8 implementations besides
>>> reference implementation (Oracle) comes without. IBM certainly does.
>>>
>>> The above page is about "Java SE product". Java SE is a
>>> specification not a product. Oracle Java SE is a product and
>>> that does indeed contain JavaFX.
>>
>> Please point me to the Java SE specification.
>
> Language:
>
> https://docs.oracle.com/javase/specs/jls/se8/html/index.html
>
> VM:
>
> https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
>
> API:
>
> http://docs.oracle.com/javase/8/docs/api/
>
> Yes - you usually don't think about the latter as a specification.
>
> But read what it says.
>
> "This document is the API specification for the Java™ Platform, Standard
> Edition."
>
> And JavaFX is not included.
>

Well, JSR 337 page points to the reference implementation here:
<http://jdk8.java.net/java-se-8-ri/>
which I downloaded and indeed there are no javafx packages.

So, I will have to stand corrected. My apologies.

But, I will not have to like it.

[toc] | [prev] | [next] | [standalone]

#32472

On 09/02/2015 05:25 PM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>>> final javafx.beans.property.IntegerProperty height
>>> = new javafx.beans.property.SimpleIntegerProperty( 10 );
>>> final javafx.beans.property.IntegerProperty number
>>> = new javafx.beans.property.SimpleIntegerProperty(  2 );
>>> final javafx.beans.binding.NumberBinding spaces =
>>> height.subtract( number );
>>> java.lang.System.out.println( spaces.getValue() );
>>> height.set( 20 );
>>> java.lang.System.out.println( spaces.getValue() ); }} 
>> What's the java feature that makes "spaces" above update automatically?
>> To put it another way - if I didn't want such updates, what should I
>> write differently?
> 
>   This depends on the details of the behavior you want instead.

I read a bit about Java many years ago, and reached the conclusion that
it had some syntactic similarities C++, but had a very different way of
implementing objects. I played with it long enough to get something
working, but concluded that it wasn't what I needed for any purpose I
was trying to achieve at the time. I'm otherwise very unfamiliar with java.

I get the impression from what you're saying, that the code you've shown
results in each call to spaces.getValue() performing a fresh calculation
of height-number, using the values of those things at the time
getValue() is called. I'm asking about what you would have to do
differently to have spaces set to the value of height - number at one
particular time, and to have spaces.getValue() continue to report that
same value, even if the values of height and number later change. It
seems to me that this should be easier than arranging for automatic
updates - in fact, I'd expect it to be trivial.

>   For one example, you can simply omit »height.set( 20 )«, and
>   »spaces« will not be updated. Or, you could just write:

Well, I'm asking how to ensure that "spaces" will not be updated, even
if "height" is, so that doesn't qualify.

> public final class Main
> { public static void main( final java.lang.String[] args )
>   { final javafx.beans.property.IntegerProperty spaces
>     = new javafx.beans.property.SimpleIntegerProperty( 8 );
>     java.lang.System.out.println( spaces.getValue() ); }}
> 
>   Which just will print »8« and not update spaces, or just
>
> public final class Main
> { public static void main( final java.lang.String[] args )
>   { int const spaces = 8; java.lang.System.out.println( spaces ); }}

Those both set spaces to 8, rather than height - number. If
height-number is currently 8, that happens to be the right value, but
isn't what I'm looking for.

>   or just,
> 
> public final class Main
> { public static void main( final java.lang.String[] args )
>   { java.lang.System.out.println( 8 ); }}
> 
>   to get the same behavior.

That seems to print out 8 without even storing it anywhere, and without
any connection to "height" or "number".

[toc] | [prev] | [next] | [standalone]

#32475

On 09/02/2015 07:13 PM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> Those both set spaces to 8, rather than height - number. If
>> height-number is currently 8, that happens to be the right value, but
>> isn't what I'm looking for.
> 
>   If you just want to set »spaces« to »height - number« once,
>   with no further update:
...
>     final javafx.beans.property.IntegerProperty spaces
>     = new javafx.beans.property.SimpleIntegerProperty
>     ( height.getValue() - number.getValue() );

So, using C++ as an analogy that I'm more familiar with, this constructs
"spaces" as a SimpleIntegerProperty initialized with the value of that
expression, which never gets re-evaluated.

Your earlier version had:
>     final javafx.beans.binding.NumberBinding spaces =
>     height.subtract( number );

which causes spaces.getValue() to behave like the equivalent of a C++
member function whose return value is calculated using the specified
formula freshly each time "spaces" is referred to. Is this a
characteristic of binding.NumberBinding, or some more general Java feature?

Have I got that right?

In C++, the equivalent of the first form above would be simpler than the
equivalent of the second form, so it feels odd that the second form is
simpler in Java. I'll try to keep that in mind should I ever need to
program in Java again. It sounds like I've got a lot to learn before I
even get started.

[toc] | [prev] | [next] | [standalone]

#32482

On 09/02/2015 07:28 PM, James Kuyper wrote:
> On 09/02/2015 07:13 PM, Stefan Ram wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> Those both set spaces to 8, rather than height - number. If
>>> height-number is currently 8, that happens to be the right value, but
>>> isn't what I'm looking for.
>>
>>    If you just want to set »spaces« to »height - number« once,
>>    with no further update:
> ...
>>      final javafx.beans.property.IntegerProperty spaces
>>      = new javafx.beans.property.SimpleIntegerProperty
>>      ( height.getValue() - number.getValue() );
>
> So, using C++ as an analogy that I'm more familiar with, this constructs
> "spaces" as a SimpleIntegerProperty initialized with the value of that
> expression, which never gets re-evaluated.
>
> Your earlier version had:
>>      final javafx.beans.binding.NumberBinding spaces =
>>      height.subtract( number );
>
> which causes spaces.getValue() to behave like the equivalent of a C++
> member function whose return value is calculated using the specified
> formula freshly each time "spaces" is referred to. Is this a
> characteristic of binding.NumberBinding, or some more general Java feature?

It's a characteristic of the
javafx.beans.binding.Binding<T> interface.
<https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/Binding.html>

Which depends upon the arguably more general
javafx.beans.Observable and
javafx.beans.value.ObservableValue<T> interfaces.

>
> Have I got that right?
>
> In C++, the equivalent of the first form above would be simpler than the
> equivalent of the second form, so it feels odd that the second form is
> simpler in Java. I'll try to keep that in mind should I ever need to
> program in Java again. It sounds like I've got a lot to learn before I
> even get started.
>

[toc] | [prev] | [next] | [standalone]

#32489

On 09/02/2015 11:52 PM, Jeff Higgins wrote:
> On 09/02/2015 07:28 PM, James Kuyper wrote:

>> Your earlier version had:
>>>      final javafx.beans.binding.NumberBinding spaces =
>>>      height.subtract( number );
>>
>> which causes spaces.getValue() to behave like the equivalent of a C++
>> member function whose return value is calculated using the specified
>> formula freshly each time "spaces" is referred to. Is this a
>> characteristic of binding.NumberBinding, or some more general Java
>> feature?
>
> It's a characteristic of the
> javafx.beans.binding.Binding<T> interface.
> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/Binding.html>
>

Sorry, this is incorrect.
It's a characteristic of the
javafx.beans.property.Property<T> interface.
<https://docs.oracle.com/javase/8/javafx/api/javafx/beans/property/Property.html>

[toc] | [prev] | [next] | [standalone]

#32490

On 09/03/2015 10:32 AM, Jeff Higgins wrote:
> On 09/02/2015 11:52 PM, Jeff Higgins wrote:
>> On 09/02/2015 07:28 PM, James Kuyper wrote:
> 
>>> Your earlier version had:
>>>>      final javafx.beans.binding.NumberBinding spaces =
>>>>      height.subtract( number );
>>>
>>> which causes spaces.getValue() to behave like the equivalent of a C++
>>> member function whose return value is calculated using the specified
>>> formula freshly each time "spaces" is referred to. Is this a
>>> characteristic of binding.NumberBinding, or some more general Java
>>> feature?
>>
>> It's a characteristic of the
>> javafx.beans.binding.Binding<T> interface.
>> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/Binding.html>
>>
> 
> Sorry, this is incorrect.
> It's a characteristic of the
> javafx.beans.property.Property<T> interface.
> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/property/Property.html>

According to Stefan Ram, using the following code:
>     final javafx.beans.binding.NumberBinding spaces =
>     height.subtract( number );

would cause the subtraction to be re-evaluated with the current values
of height and number, each time spaces.getValue() is called, while


>     final javafx.beans.property.IntegerProperty spaces
>     = new javafx.beans.property.SimpleIntegerProperty
>     ( height.getValue() - number.getValue() );

would cause the subtraction to be performed only once, when spaces is
created. Are you saying he got those reversed? Or something more
complicated than that?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#32493

On 09/03/2015 10:53 AM, James Kuyper wrote:
> On 09/03/2015 10:32 AM, Jeff Higgins wrote:
>> On 09/02/2015 11:52 PM, Jeff Higgins wrote:
>>> On 09/02/2015 07:28 PM, James Kuyper wrote:
>>
>>>> Your earlier version had:
>>>>>       final javafx.beans.binding.NumberBinding spaces =
>>>>>       height.subtract( number );
>>>>
>>>> which causes spaces.getValue() to behave like the equivalent of a C++
>>>> member function whose return value is calculated using the specified
>>>> formula freshly each time "spaces" is referred to. Is this a
>>>> characteristic of binding.NumberBinding, or some more general Java
>>>> feature?
>>>
>>> It's a characteristic of the
>>> javafx.beans.binding.Binding<T> interface.
>>> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/Binding.html>
>>>
>>
>> Sorry, this is incorrect.
>> It's a characteristic of the
>> javafx.beans.property.Property<T> interface.
>> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/property/Property.html>
>
> According to Stefan Ram, using the following code:
>>      final javafx.beans.binding.NumberBinding spaces =
>>      height.subtract( number );
>
> would cause the subtraction to be re-evaluated with the current values
> of height and number, each time spaces.getValue() is called, while

Correct.

>
>
>>      final javafx.beans.property.IntegerProperty spaces
>>      = new javafx.beans.property.SimpleIntegerProperty
>>      ( height.getValue() - number.getValue() );
>
> would cause the subtraction to be performed only once, when spaces is
> created. Are you saying he got those reversed?

No.

I don't know if you saw my example elsewhere in this thread.
I think it is more clear than the example provided by Stefan.
Bringing NumberBinding into the example was unfortunate IMHO.

In it, the ability to bind/unbind becomes much easier.
Despite its name, to get NumberBinding to provide bind/unbind
capabilities you must do the work yourself. As recommended in
the NumberBinding javadoc this is best done by extending a
base class implementation such as DoubleBinding. See the
DoubleBinding javadoc for example code.

[toc] | [prev] | [next] | [standalone]

#32494

On 09/03/2015 11:31 AM, Jeff Higgins wrote:
The whole javafx package is a mess of mixin interfaces
which makes it hard to discuss but fairly easy to work with.

[toc] | [prev] | [next] | [standalone]

#32495

On 09/03/2015 11:31 AM, Jeff Higgins wrote:

> I don't know if you saw my example elsewhere in this thread.
In it, the ability to bind/unbind becomes much easier.
> I think it is more clear than the example provided by Stefan.
> Bringing NumberBinding into the example was unfortunate IMHO.
>
>
> Despite its name, to get NumberBinding to provide bind/unbind
> capabilities you must do the work yourself. As recommended in
> the NumberBinding javadoc this is best done by extending a
> base class implementation such as DoubleBinding. See the
> DoubleBinding javadoc for example code.
>

[toc] | [prev] | [next] | [standalone]

#32497

On 09/03/2015 11:31 AM, Jeff Higgins wrote:
> On 09/03/2015 10:53 AM, James Kuyper wrote:
>> On 09/03/2015 10:32 AM, Jeff Higgins wrote:
>>> On 09/02/2015 11:52 PM, Jeff Higgins wrote:
>>>> On 09/02/2015 07:28 PM, James Kuyper wrote:
>>>
>>>>> Your earlier version had:
>>>>>>       final javafx.beans.binding.NumberBinding spaces =
>>>>>>       height.subtract( number );
>>>>>
>>>>> which causes spaces.getValue() to behave like the equivalent of a C++
>>>>> member function whose return value is calculated using the specified
>>>>> formula freshly each time "spaces" is referred to. Is this a
>>>>> characteristic of binding.NumberBinding, or some more general Java
>>>>> feature?
>>>>
>>>> It's a characteristic of the
>>>> javafx.beans.binding.Binding<T> interface.
>>>> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/Binding.html>
>>>>
>>>
>>> Sorry, this is incorrect.
>>> It's a characteristic of the
>>> javafx.beans.property.Property<T> interface.
>>> <https://docs.oracle.com/javase/8/javafx/api/javafx/beans/property/Property.html>
>>
>> According to Stefan Ram, using the following code:
>>>      final javafx.beans.binding.NumberBinding spaces =
>>>      height.subtract( number );
>>
>> would cause the subtraction to be re-evaluated with the current values
>> of height and number, each time spaces.getValue() is called, while
> 
> Correct.
> 
>>
>>
>>>      final javafx.beans.property.IntegerProperty spaces
>>>      = new javafx.beans.property.SimpleIntegerProperty
>>>      ( height.getValue() - number.getValue() );
>>
>> would cause the subtraction to be performed only once, when spaces is
>> created. Are you saying he got those reversed?
> 
> No.

OK - I thought I was beginning to understand  what was going on, but now
I'm thoroughly confused. You're saying that this behavior (Specifically,
the behavior of re-calculating the subtraction each time
spaces.getValue() is used) is a property of the
javafx.beans.property.Property<T> interface, rather than a property of
the javafx.beans.binding.Binding<T> interface, despite the fact that it
happens when he uses javafx.beans.binding.NumberBinding, and doesn't
happen when he uses javafx.beans.property.SimpleIntegerProperty?

How does that work? Does javafx.beans.binding.NumberBinding use
javafx.beans.property.Property<T> while
javafx.beans.property.SimpleIntegerProperty uses
javafx.beans.binding.Binding<T>? That's not at all what I would have
expected, based solely upon the names.


-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web