Consider the more general "function class" pattern

[domenic]

A continuation of #11, with more focus, since that was cleaned up. As discussed there, observables are an instance of the "function class" pattern, specifically for functions of the signature { next, return, throw } -> { unsubscribe }.

Function class is to me a more compelling general pattern to consider introducing into the language than the specific instance of observables. For example, a function class built around Promise -> void would allow lazy transformations on single asynchronous values.

I'd like this proposal to give more consideration to how it fits with the general function class idea. For example, it seems likely that Observable should be a subclass of Function. That would also help avoid any bikeshedding over [Symbol.observe] vs. subscribe or similar.

[benlesh]

@domenic I need to more elaborate straw-man to understand what you're suggesting. Can you type up an example?

[trxcllnt]

@Blesh I remember mentioning a potential Function.create to @domenic in New York last year, and this sounds like the same idea. Essentially, something like:

// polyfill
Function.create = (proto, body) => {
    let newFn = (...args) => { return body(...args); };
    for(var key in proto) {
        if(proto.hasOwnProperty(key)) {
            newFn[key] = proto[key];
        }
    }
    return newFn;
};

let randomNumbersObs = Function.create(Observable.prototype, (observer) => {
    let id = setInterval(() => observer.next(Math.random()), 100);
    return _ => clearInterval(id);
});

let dispose = randomNumbersObs.map((i) => { value: i })({
    next(x) { console.log(x.value); }
});

[benlesh]

that is pretty interesting. As an orthogonal proposal, I think that's useful.

The real problem is that everyone would have to reimplement the guarantees of Observable. There is some inherent behavior in observable that pretty much requires it be a type.

[benjamingr]

@Blesh well, it relates to observables (and other types) in interesting ways.

    class Observable extends Function { // the same way a generator is a function
        constructor(fn) { ... }
        map(fn) { ... }
        ...
        call(subscriber){
             // this is `.subscribe`
        }
    }

Which would make the API look like:

 var o = myObservableReturningFn.map(..).filter(...);

 o(v => console.log(v));

Instead of:

var o = myObservableReturningFn(...).map(..).filter(...);
o.subscribe(v => console.log(v));

The interesting thing is that because a function class is just an implementation of the continuation comonad we can apply this "non-strictness at invocation" to anything, functions returning arrays, promises or whatever. The limitation is that this comonad needs to be applied on a functor itself. We are basically building and composing functions here based on the return type getting an interesting signature of:

-- takes a function to `a` and return a function to `a` which is also an `a`
bind:: (() -> a) -> (a & (() -> a))

With a sufficiently clever typesystem this would be possible, in JS I don't think it is. We can settle for particular instances or "applying this pattern in the language". So the laziness is in not calling the function and not in an implicit laziness contract.

[zenparsing]

I think the method-wrapper is important for readability, at least for Observable:

getObservable()(); // Looks weird

getObservable().subscribe(); // Better

[trxcllnt]

@zenparsing getObservable().call() is still an option, and you could implement subscribe to call under the hood.