Consider the more general "function class" pattern about es-observable HOT 6 CLOSED

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

from es-observable.

@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); }
});

from es-observable.

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.

from es-observable.

@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.

from es-observable.

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

getObservable()(); // Looks weird

getObservable().subscribe(); // Better

from es-observable.

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

from es-observable.