Including the observer pattern in the implementation of properties

[Tom]

I'm surprised how little this comes up: why isn't the observer pattern
built into more languages? Since one of the stated goals of noop is
eliminating boilerplate, one of the most common patterns of all time
seems like a logical candidate for support at the language level.

Properties seem like the right entry point for this feature. I would
like a syntax where I can easily attach an observer to any mutable
reference to hear about and react to its changing. This syntax would
allow attaching an observer as pre-notified, post-notified or both.
Perhaps pre-notified observers could also have a chance to veto the
change?

This is the kind of power that to my knowledge only aspect-oriented
languages offer at the moment, although it seems almost incidental to
their main intent.

Tom

[Ben Rady]

+1 on baked in support for the observer pattern. This pattern shows up a lot in GUI development, and Java's support of it is one reason why Swing can be such a beating.

[Alex Eagle]

Yes, I'd just call this "first-class events", and I'd like for us to
have it. Some of us have worked in Flex and that's one of the better
parts of Actionscript 3.
We haven't thought much about supporting UI code, and which libraries
to support. For example, if we want to support JavaFX, it would be
best to compile bytecodes that can access and mutate properties in the
JavaFX format, then our events can be triggered by that UI.
Also we'd like for a UI library to support binding a property to a UI
field, which depends on having events available, and auto-wiring the
events in both directions. That's probably a job for a third-party
library.
-Alex

[t0rx]

I think this is a great idea but wonder about the performance
overhead, especially if implemented in a thread-safe manner.

Or is that outweighed by the benefits?

Yan

[Christian Gruber]

I'm definitely planning to re-capture a bit of NeXTSTEP's interface builder (currently only really available through Apple for Mac and iPhone developers.  But I want GUIs that are drawn and serialized, with controller outlets (fields) bound to graphical components via adapters.  

Having a built in event system would be a great base for this.

Christian.

--
-----
Christian Gruber
christiane...@gmail.com

[John A. De Goes]

A cleaner alternative to observer pattern is reactive programming (see
http://en.wikipedia.org/wiki/Reactive_programming) built on actor
concurrency.

Observer pattern is nice but requires far too much boilerplate in
comparison to reactive programming.

[Ben Rady]

Looks cool. I can definitely see how it could remove a lot of boilerplate with the observer pattern, but I'm not sure how it would completely replace it. For example, if I wanted to write a file in response to a change in data, how could I do that reactively?

[Tom]

I like the idea of reactive programming and I think it should be
included as well, however I don't think it supersedes the need for
Observer. Sometimes it's not enough that you want a value to stay up-
to-date, you may want to execute arbitrary code *when* that value is
updated! Pseudocode example combining the two notions:

x = 1;
b.foo = x + 5;
b?foo { println(b); } // "?" is the "observe" operator that takes a
variable name within b (foo) and a closure which dictates how to
respond to changes
x++;

// prints "7"

This syntax is just off the top of my head, but it illustrates the
idea, as well as incorporating "reactive programming" (the fact that
b.foo is defined in terms of x, and therefore changing x triggers the
listener on foo).

On Nov 27, 10:50 am, "John A. De Goes" <j...@n-brain.net> wrote:
> A cleaner alternative to observer pattern is reactive programming (seehttp://en.wikipedia.org/wiki/Reactive_programming) built on actor

[Yan Tordoff]

Out of interest, what's the difference between

    b.foo = x + 5;

as a reactive assignment and
    ?x { b.foo = x + 5 };
as an observation?

[Tom]

Good question. I think the answer is just "syntactic clarity". The
former looks more readable to me, if all you want is to "define b.foo
in terms of x".

Incidentally, I think my fake syntax leaves something to be desired in
that sometimes you just want a "plain old assignment"; in other words
you just want to assign the *current binding of x* plus 5, not have it
always be defined in terms of whatever x is. For this distinction I
like Scala's syntax:

def foo = x + 5;

this essentially makes foo a no-arg function, but you can think of it
as just "foo will always be whatever x is plus 5"... since in Scala
you can leave the parens off a no-arg method, whether foo is a
variable or "reactive function" is an implementation detail. The
following, however, merely declares a constant which is assigned the
current binding of x plus 5:

val foo = x + 5;
var foo = x + 5;

On Nov 30, 12:49 pm, Yan Tordoff <t0r...@googlemail.com> wrote:
> Out of interest, what's the difference between
>     b.foo = x + 5;
> as a reactive assignment and
>     ?x { b.foo = x + 5 };
> as an observation?
>

[Yan Tordoff]

You maybe could go for a different assignment operator:

  foo := x + 5;

which you would read as "foo is defined as x + 5".