This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Binding in Scala?

5 replies
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.

Ingo Maier is working on sfx, which is a functional approach to what you want.
It's most recent committed version is on the scala svn, under scala-experimental, under sfx. Take a look at the signal tests.

-------------------------------------
JamesJ wrote:

I am relatively new to Scala. I apologize if my question/suggestion has
already been flogged to death, but after a quick search I didn't find much.

I would just like to offer a few ideas about binding. Like JavaFx, but not
quite.

I have been thinking about this for quite a few years and have come to the
conclusion that there is no single approach to binding at a high level.
Several years ago I wrote my own binding library for Java that describes
interesting relationships between entities in a way that provided what I
wanted for desk top development. (But, obviously, I couldn't do the
detection of changes in entities within plain Java. You have to resort to
AOP, byte code manipulation, or just hand wiring.) The interesting thing is
that over the past few years there have been other solutions that have come
along that all do it differently based on the authors perspective and the
platform that is being targeted.

My suggestion is that Scala offer the simplest possible binding facilitation
as part of the language, and then in the spirit of scalability allow others
to write binding behavior as libraries.

My thoughts in rough form are:

First, provide a way to enhance vars with optional, integrated change
notification. I.e. something like
bindable var foo = 0
I don't really care about how the syntax would look, so much as the ability
to tell a var that at some time in the future, I may decide that I want
notification of reassignment.

Second, the implicit ability to add/remove multiple observers to vars that
have been so declared.

Third, the ability to plug in an alternate notification/registration
strategy. When an assignment happens, the default strategy would just
notify everything in the same order that observers where added. But an
alternate strategy could handle all kinds of prioritization, filtering or
smart recursion.

Fourth, if you make behavioral groups, where each group can have a separate
strategy, then the first and third point get even more flexable, so that a
library or module can use its own definition of what binding ought to do.
Something like,
bindable(grp) var foo = 0

Fifth, if you also add a kind of related functionality to also get
notification of when a var is read, then you can write clever little
networks of minimal computation, auto-updating values. (Like a spreadsheet
does, but more implicit.) With the support of language features you could
achieve this much more naturally.

I understand that there are probably lots of hairy issues involved in making
a generic feature like this, but maybe it is not so bad.

With tools like this, a lot of current listener/ notification code could be
simplified drastically. I think that Scala could offer a better binding
than JavaFx because it would ultimately be decided by the use patterns of
the community instead the decisions of a few architects.

mighdoll
Joined: 2009-02-16,
User offline. Last seen 1 year 22 weeks ago.
Re: Binding in Scala?
Hi James,

I've also wanted a good way to detect writes of scala vars.  We use a library that synchronizes scala objects to browser javascript objects, and it needs a way to observe the scala objects for changes.

Martin once suggested a language feature that would allow binding to be a library feature rather than the built into the language.  As I recall, the idea was to create an override that can override multiple setters at once.  Something in this direction I suppose:
trait Bindable {
  override def .*_=(newVal:T) = {...}  // override all setters
}

While built in language support of one form or another would be nice, a compiler plugin would be a good first step.  Kevin's autoproxy   is worth looking at here, although I don't think it addresses this case.

There are some workarounds today.  I currently use a technique involving AspectJ, which I think of as an interim solution until one of us gets around to a compiler plugin.  If you're willing to go the aspectJ route, this aspectj snippet from jsync will allow you patch all var setters. 
pointcut setScalaProperty() : execution(* Observable+.*_$eq(*));

Jonas uses an AOP generated proxy for a related problem in akka.

And of course, if you're willing to use less idiomatic vars, you can get to something like the following (Lift's mapper uses this technique):
var myStr = WatchableVar[String]("initialString")
myStr("newString")

Cheers,
Lee

On Sun, Jan 24, 2010 at 2:36 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
Ingo Maier is working on sfx, which is a functional approach to what you want.
It's most recent committed version is on the scala svn, under scala-experimental, under sfx. Take a look at the signal tests.


-------------------------------------
JamesJ<james [at] kybios [dot] com> wrote:

I am relatively new to Scala.  I apologize if my question/suggestion has
already been flogged to death, but after a quick search I didn't find much.

I would just like to offer a few ideas about binding.  Like JavaFx, but not
quite.

I have been thinking about this for quite a few years and have come to the
conclusion that there is no single approach to binding at a high level.
 Several years ago I wrote my own binding library for Java that describes
interesting relationships between entities in a way that provided what I
wanted for desk top development.  (But, obviously, I couldn't do the
detection of changes in entities within plain Java.  You have to resort to
AOP, byte code manipulation, or just hand wiring.)  The interesting thing is
that over the past few years there have been other solutions that have come
along that all do it differently based on the authors perspective and the
platform that is being targeted.

My suggestion is that Scala offer the simplest possible binding facilitation
as part of the language, and then in the spirit of scalability allow others
to write binding behavior as libraries.

My thoughts in rough form are:

First, provide a way to enhance vars with optional, integrated change
notification.  I.e. something like
  bindable var foo = 0
I don't really care about how the syntax would look, so much as the ability
to tell a var that at some time in the future, I may decide that I want
notification of reassignment.

Second, the implicit ability to add/remove multiple observers to vars that
have been  so declared.

Third, the ability to plug in an alternate notification/registration
strategy.  When an assignment happens, the default strategy would just
notify everything in the same order that observers where added.  But an
alternate strategy could handle all kinds of prioritization, filtering or
smart recursion.

Fourth, if you make behavioral groups, where each group can have a separate
strategy, then the first and third point get even more flexable, so that a
library or module can use its own definition of what binding ought to do.
 Something like,
   bindable(grp) var foo = 0

Fifth, if you also add a kind of related functionality to also get
notification of when a var is read, then you can write clever little
networks of minimal computation, auto-updating values.  (Like a spreadsheet
does, but more implicit.)  With the support of  language features you could
achieve this much more naturally.

I understand that there are probably lots of hairy issues involved in making
a generic feature like this, but maybe it is not so bad.

With tools like this, a lot of current listener/ notification code could be
simplified drastically.  I think that Scala could offer a better binding
than JavaFx because it would ultimately be decided by the use patterns of
the community instead the decisions of a few architects.

Rüdiger Keller
Joined: 2010-01-24,
User offline. Last seen 42 years 45 weeks ago.
Re: Binding in Scala?
I was thinking that perhaps something along the following lines might be comparatively easy to implement.

First a custom property handler class. Anything would be fine, just the two methods get and set would be a requirement, so that the imaginary compiler extension / plugin knows how to use the property handler (alternatively one could define a trait which needs to be extended?)

class PropertyHandler[T] {
    var value: T = _
    val observers = new ArrayBuffer[(T, T) => Unit]
 
    def get = value
    def set(newValue : T) = {
        observers.foreach(_.apply(value, newValue))
        value = newValue
    }
    def registerObserver(f: (T, T) => Unit): Unit = observers += f
}

Then some class which is using the custom property handler for its properties, with some annotation for the compiler (I chose "@Delegate" for the example here):

class Foo {
    @Delegate val _foo = new PropertyHandler[String]()
    @Delegate val _bar = new PropertyHandler[String]()
    @Delegate val _baz = new PropertyHandler[Int]()
}

This class would be expanded by the compiler to the following (via naming convention):

class Foo {
    val _foo = new PropertyHandler[String]()
    val _bar = new PropertyHandler[String]()
    val _baz = new PropertyHandler[Int]()
   
    def foo = _foo.get
    def foo_(String s) = _foo.set(s)
    def bar = _bar.get
    def bar(String s) = _bar.set(s)
    def baz = _baz.get
    def baz(Int i) = _baz.set(i)
}

It seems that Kevin Wright's autoproxy plugin has nearly all what it needs to enable this. It would just need to support this different scheme of forwarding methods.

Cheers,
Ruediger


2010/1/25 Lee Mighdoll <lee [at] underneath [dot] ca>
Hi James,

I've also wanted a good way to detect writes of scala vars.  We use a library that synchronizes scala objects to browser javascript objects, and it needs a way to observe the scala objects for changes.

Martin once suggested a language feature that would allow binding to be a library feature rather than the built into the language.  As I recall, the idea was to create an override that can override multiple setters at once.  Something in this direction I suppose:
trait Bindable {
  override def .*_=(newVal:T) = {...}  // override all setters
}

While built in language support of one form or another would be nice, a compiler plugin would be a good first step.  Kevin's autoproxy   is worth looking at here, although I don't think it addresses this case.

There are some workarounds today.  I currently use a technique involving AspectJ, which I think of as an interim solution until one of us gets around to a compiler plugin.  If you're willing to go the aspectJ route, this aspectj snippet from jsync will allow you patch all var setters. 
pointcut setScalaProperty() : execution(* Observable+.*_$eq(*));

Jonas uses an AOP generated proxy for a related problem in akka.

And of course, if you're willing to use less idiomatic vars, you can get to something like the following (Lift's mapper uses this technique):
var myStr = WatchableVar[String]("initialString")
myStr("newString")

Cheers,
Lee

On Sun, Jan 24, 2010 at 2:36 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
Ingo Maier is working on sfx, which is a functional approach to what you want.
It's most recent committed version is on the scala svn, under scala-experimental, under sfx. Take a look at the signal tests.


-------------------------------------
JamesJ<james [at] kybios [dot] com> wrote:

I am relatively new to Scala.  I apologize if my question/suggestion has
already been flogged to death, but after a quick search I didn't find much.

I would just like to offer a few ideas about binding.  Like JavaFx, but not
quite.

I have been thinking about this for quite a few years and have come to the
conclusion that there is no single approach to binding at a high level.
 Several years ago I wrote my own binding library for Java that describes
interesting relationships between entities in a way that provided what I
wanted for desk top development.  (But, obviously, I couldn't do the
detection of changes in entities within plain Java.  You have to resort to
AOP, byte code manipulation, or just hand wiring.)  The interesting thing is
that over the past few years there have been other solutions that have come
along that all do it differently based on the authors perspective and the
platform that is being targeted.

My suggestion is that Scala offer the simplest possible binding facilitation
as part of the language, and then in the spirit of scalability allow others
to write binding behavior as libraries.

My thoughts in rough form are:

First, provide a way to enhance vars with optional, integrated change
notification.  I.e. something like
  bindable var foo = 0
I don't really care about how the syntax would look, so much as the ability
to tell a var that at some time in the future, I may decide that I want
notification of reassignment.

Second, the implicit ability to add/remove multiple observers to vars that
have been  so declared.

Third, the ability to plug in an alternate notification/registration
strategy.  When an assignment happens, the default strategy would just
notify everything in the same order that observers where added.  But an
alternate strategy could handle all kinds of prioritization, filtering or
smart recursion.

Fourth, if you make behavioral groups, where each group can have a separate
strategy, then the first and third point get even more flexable, so that a
library or module can use its own definition of what binding ought to do.
 Something like,
   bindable(grp) var foo = 0

Fifth, if you also add a kind of related functionality to also get
notification of when a var is read, then you can write clever little
networks of minimal computation, auto-updating values.  (Like a spreadsheet
does, but more implicit.)  With the support of  language features you could
achieve this much more naturally.

I understand that there are probably lots of hairy issues involved in making
a generic feature like this, but maybe it is not so bad.

With tools like this, a lot of current listener/ notification code could be
simplified drastically.  I think that Scala could offer a better binding
than JavaFx because it would ultimately be decided by the use patterns of
the community instead the decisions of a few architects.


mighdoll
Joined: 2009-02-16,
User offline. Last seen 1 year 22 weeks ago.
Re: Binding in Scala?
I like that such an approach would make things transparent to the users of the library, which is probably the most important thing.

The class definition of Foo looks pretty awkward though.  Looks like it breaks java POJO compatibility too, because it doesn't generate the expected primitive fields.  So no JPA on Foo, which would be unfortunate.  Similarly, seems likely that @BeanProperty wouldn't work with Foo.

I really don't know what's hard to do in a plugin, so it's probably not much worth speculating much on syntax at this point.  I'll nibble nonetheless:

public @interface Bindable   // TBD tell the plugin that this means @Delegate to a PropertyHandler

class Bag {
  @Bindable var foo = ""
  @Bindable var foz = ""
}

@Bindable // mark all vars bindable
class Bag { 
  var foo = ""
  var foz = ""
}

@Bindable trait BindableTrait
class Bag extends BindableTrait {  // mark all vars bindable (?)
  var foo = ""
  var foz = ""
}


Lee

Mon, Jan 25, 2010 at 3:12 PM, Rüdiger Keller <ruediger [dot] keller [at] googlemail [dot] com> wrote:
I was thinking that perhaps something along the following lines might be comparatively easy to implement.

First a custom property handler class. Anything would be fine, just the two methods get and set would be a requirement, so that the imaginary compiler extension / plugin knows how to use the property handler (alternatively one could define a trait which needs to be extended?)

class PropertyHandler[T] {
    var value: T = _
    val observers = new ArrayBuffer[(T, T) => Unit]
 
    def get = value
    def set(newValue : T) = {
        observers.foreach(_.apply(value, newValue))
        value = newValue
    }
    def registerObserver(f: (T, T) => Unit): Unit = observers += f
}

Then some class which is using the custom property handler for its properties, with some annotation for the compiler (I chose "@Delegate" for the example here):

class Foo {
    @Delegate val _foo = new PropertyHandler[String]()
    @Delegate val _bar = new PropertyHandler[String]()
    @Delegate val _baz = new PropertyHandler[Int]()
}

This class would be expanded by the compiler to the following (via naming convention):

class Foo {
    val _foo = new PropertyHandler[String]()
    val _bar = new PropertyHandler[String]()
    val _baz = new PropertyHandler[Int]()
   
    def foo = _foo.get
    def foo_(String s) = _foo.set(s)
    def bar = _bar.get
    def bar(String s) = _bar.set(s)
    def baz = _baz.get
    def baz(Int i) = _baz.set(i)
}

It seems that Kevin Wright's autoproxy plugin has nearly all what it needs to enable this. It would just need to support this different scheme of forwarding methods.

Cheers,
Ruediger


2010/1/25 Lee Mighdoll <lee [at] underneath [dot] ca>
Hi James,

I've also wanted a good way to detect writes of scala vars.  We use a library that synchronizes scala objects to browser javascript objects, and it needs a way to observe the scala objects for changes.

Martin once suggested a language feature that would allow binding to be a library feature rather than the built into the language.  As I recall, the idea was to create an override that can override multiple setters at once.  Something in this direction I suppose:
trait Bindable {
  override def .*_=(newVal:T) = {...}  // override all setters
}

While built in language support of one form or another would be nice, a compiler plugin would be a good first step.  Kevin's autoproxy   is worth looking at here, although I don't think it addresses this case.

There are some workarounds today.  I currently use a technique involving AspectJ, which I think of as an interim solution until one of us gets around to a compiler plugin.  If you're willing to go the aspectJ route, this aspectj snippet from jsync will allow you patch all var setters. 
pointcut setScalaProperty() : execution(* Observable+.*_$eq(*));

Jonas uses an AOP generated proxy for a related problem in akka.

And of course, if you're willing to use less idiomatic vars, you can get to something like the following (Lift's mapper uses this technique):
var myStr = WatchableVar[String]("initialString")
myStr("newString")

Cheers,
Lee

On Sun, Jan 24, 2010 at 2:36 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
Ingo Maier is working on sfx, which is a functional approach to what you want.
It's most recent committed version is on the scala svn, under scala-experimental, under sfx. Take a look at the signal tests.


-------------------------------------
JamesJ<james [at] kybios [dot] com> wrote:

I am relatively new to Scala.  I apologize if my question/suggestion has
already been flogged to death, but after a quick search I didn't find much.

I would just like to offer a few ideas about binding.  Like JavaFx, but not
quite.

I have been thinking about this for quite a few years and have come to the
conclusion that there is no single approach to binding at a high level.
 Several years ago I wrote my own binding library for Java that describes
interesting relationships between entities in a way that provided what I
wanted for desk top development.  (But, obviously, I couldn't do the
detection of changes in entities within plain Java.  You have to resort to
AOP, byte code manipulation, or just hand wiring.)  The interesting thing is
that over the past few years there have been other solutions that have come
along that all do it differently based on the authors perspective and the
platform that is being targeted.

My suggestion is that Scala offer the simplest possible binding facilitation
as part of the language, and then in the spirit of scalability allow others
to write binding behavior as libraries.

My thoughts in rough form are:

First, provide a way to enhance vars with optional, integrated change
notification.  I.e. something like
  bindable var foo = 0
I don't really care about how the syntax would look, so much as the ability
to tell a var that at some time in the future, I may decide that I want
notification of reassignment.

Second, the implicit ability to add/remove multiple observers to vars that
have been  so declared.

Third, the ability to plug in an alternate notification/registration
strategy.  When an assignment happens, the default strategy would just
notify everything in the same order that observers where added.  But an
alternate strategy could handle all kinds of prioritization, filtering or
smart recursion.

Fourth, if you make behavioral groups, where each group can have a separate
strategy, then the first and third point get even more flexable, so that a
library or module can use its own definition of what binding ought to do.
 Something like,
   bindable(grp) var foo = 0

Fifth, if you also add a kind of related functionality to also get
notification of when a var is read, then you can write clever little
networks of minimal computation, auto-updating values.  (Like a spreadsheet
does, but more implicit.)  With the support of  language features you could
achieve this much more naturally.

I understand that there are probably lots of hairy issues involved in making
a generic feature like this, but maybe it is not so bad.

With tools like this, a lot of current listener/ notification code could be
simplified drastically.  I think that Scala could offer a better binding
than JavaFx because it would ultimately be decided by the use patterns of
the community instead the decisions of a few architects.



Rüdiger Keller
Joined: 2010-01-24,
User offline. Last seen 42 years 45 weeks ago.
Re: Binding in Scala?
Hello Lee,

Java bean compatibility should also be addressed, I agree. One could use another annotation, that directs the compiler to create Java-bean setters and getters. Perhaps one could even reuse the @BeanProperty for this. This would then look like this:

class Foo {
    @Delegate @BeanProperty val _foo = new PropertyHandler[String]()
    @Delegate @BeanProperty val _bar = new PropertyHandler[String]()
    @Delegate @BeanProperty val _baz = new PropertyHandler[Int]()
}

I agree, that this is not too elegant, but I think this is still ok.

If I understand you suggestion correctly, you would need some way to specify the class used as a PropertyHandler. In my opinion, it should be easily possible to use custom PropertyHandlers. It would be possible with a parameter to the annotation, leading to code like this:

@Bindable(classOf[MyCustomProperyHandler])
class Bag { 
  var foo = ""
  var foz = ""
}

What do you think?

But there is also the problem of Instantiation of the PropertyHandler. If you require the compiler to create code for instantiation of the PropertyHandler, then it would probably require a parameterless constructor. This could be limiting in some cases, I imagine.

Also, I think you need to be able to access the PropertyHandler, i.e. for registering listeners. How would you do that in your example?

Ruediger


2010/1/26 Lee Mighdoll <lee [at] underneath [dot] ca>
I like that such an approach would make things transparent to the users of the library, which is probably the most important thing.

The class definition of Foo looks pretty awkward though.  Looks like it breaks java POJO compatibility too, because it doesn't generate the expected primitive fields.  So no JPA on Foo, which would be unfortunate.  Similarly, seems likely that @BeanProperty wouldn't work with Foo.

I really don't know what's hard to do in a plugin, so it's probably not much worth speculating much on syntax at this point.  I'll nibble nonetheless:

public @interface Bindable   // TBD tell the plugin that this means @Delegate to a PropertyHandler

class Bag {
  @Bindable var foo = ""
  @Bindable var foz = ""
}

@Bindable // mark all vars bindable
class Bag { 
  var foo = ""
  var foz = ""
}

@Bindable trait BindableTrait
class Bag extends BindableTrait {  // mark all vars bindable (?)
  var foo = ""
  var foz = ""
}


Lee

Mon, Jan 25, 2010 at 3:12 PM, Rüdiger Keller <ruediger [dot] keller [at] googlemail [dot] com> wrote:
I was thinking that perhaps something along the following lines might be comparatively easy to implement.

First a custom property handler class. Anything would be fine, just the two methods get and set would be a requirement, so that the imaginary compiler extension / plugin knows how to use the property handler (alternatively one could define a trait which needs to be extended?)

class PropertyHandler[T] {
    var value: T = _
    val observers = new ArrayBuffer[(T, T) => Unit]
 
    def get = value
    def set(newValue : T) = {
        observers.foreach(_.apply(value, newValue))
        value = newValue
    }
    def registerObserver(f: (T, T) => Unit): Unit = observers += f
}

Then some class which is using the custom property handler for its properties, with some annotation for the compiler (I chose "@Delegate" for the example here):

class Foo {
    @Delegate val _foo = new PropertyHandler[String]()
    @Delegate val _bar = new PropertyHandler[String]()
    @Delegate val _baz = new PropertyHandler[Int]()
}

This class would be expanded by the compiler to the following (via naming convention):

class Foo {
    val _foo = new PropertyHandler[String]()
    val _bar = new PropertyHandler[String]()
    val _baz = new PropertyHandler[Int]()
   
    def foo = _foo.get
    def foo_(String s) = _foo.set(s)
    def bar = _bar.get
    def bar(String s) = _bar.set(s)
    def baz = _baz.get
    def baz(Int i) = _baz.set(i)
}

It seems that Kevin Wright's autoproxy plugin has nearly all what it needs to enable this. It would just need to support this different scheme of forwarding methods.

Cheers,
Ruediger


2010/1/25 Lee Mighdoll <lee [at] underneath [dot] ca>
Hi James,

I've also wanted a good way to detect writes of scala vars.  We use a library that synchronizes scala objects to browser javascript objects, and it needs a way to observe the scala objects for changes.

Martin once suggested a language feature that would allow binding to be a library feature rather than the built into the language.  As I recall, the idea was to create an override that can override multiple setters at once.  Something in this direction I suppose:
trait Bindable {
  override def .*_=(newVal:T) = {...}  // override all setters
}

While built in language support of one form or another would be nice, a compiler plugin would be a good first step.  Kevin's autoproxy   is worth looking at here, although I don't think it addresses this case.

There are some workarounds today.  I currently use a technique involving AspectJ, which I think of as an interim solution until one of us gets around to a compiler plugin.  If you're willing to go the aspectJ route, this aspectj snippet from jsync will allow you patch all var setters. 
pointcut setScalaProperty() : execution(* Observable+.*_$eq(*));

Jonas uses an AOP generated proxy for a related problem in akka.

And of course, if you're willing to use less idiomatic vars, you can get to something like the following (Lift's mapper uses this technique):
var myStr = WatchableVar[String]("initialString")
myStr("newString")

Cheers,
Lee

On Sun, Jan 24, 2010 at 2:36 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
Ingo Maier is working on sfx, which is a functional approach to what you want.
It's most recent committed version is on the scala svn, under scala-experimental, under sfx. Take a look at the signal tests.


-------------------------------------
JamesJ<james [at] kybios [dot] com> wrote:

I am relatively new to Scala.  I apologize if my question/suggestion has
already been flogged to death, but after a quick search I didn't find much.

I would just like to offer a few ideas about binding.  Like JavaFx, but not
quite.

I have been thinking about this for quite a few years and have come to the
conclusion that there is no single approach to binding at a high level.
 Several years ago I wrote my own binding library for Java that describes
interesting relationships between entities in a way that provided what I
wanted for desk top development.  (But, obviously, I couldn't do the
detection of changes in entities within plain Java.  You have to resort to
AOP, byte code manipulation, or just hand wiring.)  The interesting thing is
that over the past few years there have been other solutions that have come
along that all do it differently based on the authors perspective and the
platform that is being targeted.

My suggestion is that Scala offer the simplest possible binding facilitation
as part of the language, and then in the spirit of scalability allow others
to write binding behavior as libraries.

My thoughts in rough form are:

First, provide a way to enhance vars with optional, integrated change
notification.  I.e. something like
  bindable var foo = 0
I don't really care about how the syntax would look, so much as the ability
to tell a var that at some time in the future, I may decide that I want
notification of reassignment.

Second, the implicit ability to add/remove multiple observers to vars that
have been  so declared.

Third, the ability to plug in an alternate notification/registration
strategy.  When an assignment happens, the default strategy would just
notify everything in the same order that observers where added.  But an
alternate strategy could handle all kinds of prioritization, filtering or
smart recursion.

Fourth, if you make behavioral groups, where each group can have a separate
strategy, then the first and third point get even more flexable, so that a
library or module can use its own definition of what binding ought to do.
 Something like,
   bindable(grp) var foo = 0

Fifth, if you also add a kind of related functionality to also get
notification of when a var is read, then you can write clever little
networks of minimal computation, auto-updating values.  (Like a spreadsheet
does, but more implicit.)  With the support of  language features you could
achieve this much more naturally.

I understand that there are probably lots of hairy issues involved in making
a generic feature like this, but maybe it is not so bad.

With tools like this, a lot of current listener/ notification code could be
simplified drastically.  I think that Scala could offer a better binding
than JavaFx because it would ultimately be decided by the use patterns of
the community instead the decisions of a few architects.




mighdoll
Joined: 2009-02-16,
User offline. Last seen 1 year 22 weeks ago.
Re: Binding in Scala?
I think you understand what I'm doing, but to be concrete and also to explain the java compability issue, here's an example.  I can more or less do this now, although unfortunately it needs some aspectJ awkwardness today.  

@Entity // JPA support
class Person (var firstName:String, var lastName:String)
    extends Syncable // sync support
{
    def this() = this("", "")
}

person.firstName = "fred"
// "fred" is saved to the database automatically, via JPA
// "fred" is sent to the browser automatically, via sync


On Tue, Jan 26, 2010 at 4:06 AM, Rüdiger Keller <ruediger [dot] keller [at] googlemail [dot] com> wrote:

@Bindable(classOf[MyCustomProperyHandler])
class Bag { 
  var foo = ""
  var foz = ""
}

What do you think?


I like that it's simpler :-). 

Also, I think you need to be able to access the PropertyHandler, i.e. for registering listeners. How would you do that in your example?

I watch all properties at once, so the Syncable trait can just have a single 'changes' binding that collects changes from all properties, or  MyPropertyHandler can report changes globally to a manager.
 
Per property binding points are more flexible though.  If it were available, I'm guessing that a @BeanProperty approach would also work for my case, even with underlying field is a PropertyHandler[String] instead of a String.  Most java libraries should be happy with getters/setters instead of raw properties. 

Alternately, the generated code could insert new fields into the class to be per property binding points.  That keeps the original properties more natural.  The scala class would seem like it was:
class Bag { 
  var foo:String    // extra code inserted into foo_=()
  var fooEvents:PropertyEvents[String]  // generated
}

Cheers,
Lee

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland