CallStream. An JavaScript Interfacing Pattern

I am one of those people who think that JavaScript should not be changed. No new keywords should be added. If nothing some should be removed , like ‘new’ for example. But there is one concept and one keyword which is missing: interface
Originaly published 2010 Mar 05

Class inheritance is evil. Inteface inheritance is a “good thing”. It is the key concept which delivers high degree of decoupling and encapsulation. Two corner stone OO concepts. To actually implement them , interfaces are necessary. And by this I do not mean classes pretending to be interfaces.I mean pure interfaces. I like JavaScripts prototypical nature. The concept of “class” is unnecessary to write great OO code. Keep that in mind. Generic programming and interfaces that is all that is needed. Maybe you did not know that, but even C++, does not enforces classes onto you. Standard C++ library (aka “STL”) is prime example what narrow and precise interfaces + generic progamming can do. JavaScript is much “poorer” language, than C++, but still extremelly expressive. I am using it a lot, and I allways miss interface concept, implemented directly in a javascript language.

So, I suppose this new javascript pattern, I am toying with, might be important. This is closest I ever come to having interfaces in JavaScript. It is delivering an decoupled communication, or  “interfacing”, with some state “in the back”. Simply by proviiding a mechanism for creating a stream of function calls, “anchored” and conceptualised as one call.

It is important so I shall emphasize it : this is not an Interface, that is mising from JavaScript. Rather this is communication mechanism that I propose to be used ubiquitously, to achieve the highest degree of decoupling between implementations and their callers. The interface here is in the mechanisms and communication kind used which is: messaging. I propose non-trivial JavaScript programs to be entirely composed in this way.

I have very high hopes for this mechanism and communication pattern, and I shell describe it here, step-by-step. Let’s perform an “deep plunge” first :

// (c) 2010 by DBJ.ORG , MIT licence
function CallStream ( ) { return CallStream; }

That is it. The pattern I am describing here I shall call: “Call Stream” interfacing pattern. It is an javascript mechanism. In its simplest and purest form. Just a concept, described in code. A very simple coding idiom. A function whose call, returns that same function itslef.

With the snippet and function above we can write this most exciting, piece of javascript.

// stream of calls. All under one "CallStream"
CallStream ()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()() ;

Besides the fact that above code is useless, it actually is legal javascript and it works. We can write an endless “stream of calls” , just by calling this crazy “CallStream” first. We can compose the chain of calls, starting with this one call first. Hence the name “Call Stream”. Of course, we can pass any number of any kind of arguments to any of these calls. As naturally as any other javascript code does.

// stream of calls. All under one "CallStream"
CallStream (1)(true)(new Date)([4,5,6])({a:1})(document.body)
(navigator)(true)(function(){})(false)()()()() ; // ad infinitum

Remember. All of this call’s the same function: CallStream(). So we can collect the arguments and do something with them, before next call comes in.

// (c) 2010 by DBJ.ORG , MIT licence
function CallStream ( ) {
   // here do something with arguments
   call_handler ( arguments ) ;
   // return CallStream for next call
   return CallStream;
}

Above call_handler(), is an gateway to anything. Anything that can do something with some arguments passed to the CallStream(). Different CallStreams can be made just by using different call_handler’s.

// different meta callers are made by using different call_handler's
function CallStreamOne ( ) {
   call_handler_one ( arguments ) ;   return CallStreamOne;
}
function CallStreamTwo ( ) {
   call_handler_two ( arguments ) ;   return CallStreamTwo;
}

I think that by now I can prove that CallStream pattern decouples interface from implementation. It delivers the interface as a separate entity. And. it provides interface with no methods.
It is a kind-of-a interface. And very flexible one indeed. Specific CallStream needs almost never be changed. It is very resilient to change in the underlying state to which it passes arguments. It does not want to know anything about arguments. It just want’s to pass them.

I think here I have an pattern with well defined, narrow and single purpose of existence. To allow call streaming (aka chaining), and nothing else. Nice. Perhaps. Still a bit useless. How do we make this usefull? Maybe by finding an very good “counter” example? jQuery call chaining perhaps?

These days “call chaining” is very popular and fashionable javascript sport. jQuery crowd can’t have enough of call chaining. Perhaps I can use my CallStream to devise some new and “awesome” call chaining mechanism, better than jQuery does? Although jQuery uses what some might call “simpler” and more “normal looking” form :

$("selector").find("div").attr("A",1).css("color", "#fff") ; // and on, and on ...

Function $() returns an object ,where each public method of that object returns, again the same object. Above chain calling syntax is actually very efficient and leads to smaller and more efficient code. It is also logical. Because all calls in a chain, naturally are working on the same underlying state (dom nodes) , which is defined by the first call to the jQuery itself. After seeing this for the first time, and an initial “javascript cultural shock” it is easy to understand that jQuery chain deals with the same instance of an jQuery object. As defined with the first call, which has selected some dom node set.
Ok, but how is “CallStream” performing when compared to this “traditional call chaining”? This is how. Imagine jQuery version which is based on “CallStream” , and let us try and repeat the chain above, shall we ?

// jQuery interface based on CallStream uasge
$("selector")(find,"div")(attr,"A",1)(css,"color", "#fff") ; // chain proceeds here...

What do I see above? First of all everything becomes much more flexible. How so? Simple: there is no ‘.’ (dot) operator. Functions used can come from anywhere. Functions used can be changed in a totaly free manner. They are not attached to jQuery. “find”, “attr” and “css” might be jQuery “aware” functions or they might be any other functions which “know” how to achieve the required result. They are “trully functional”! therefore they can be 100% re-usable. They might work on two, or more , similar , but different “CallStreams”. It is just a question of “contract” they have to oblige to. These functions can even be used at runtime, on several widly different instances of CallStreams. They can become “StreamVisitors”. Generic Functions re-used (aka “called”) on many different CallStream instances. Example is due.

// StreamVisitor re-usability
CallStream("#container")(find,"div")(attr,"A",1)(css,"color", "#fff")(logger) ;
// logger is a StreamVisitor
CallStream("#toolbar")(css,"color", "#fff")(logger) ; // logger re-used

Function “logger” above is a “StreamVisitor”. Without any change, one single generic function is used to send logs from any jQuery instance. The “StreamVisitor” requirements are in the “contract”. They need not follow any dependancy on some another functions or objects. And all of that without any extra “plugin” mechanism. Every function in this stream of calls is a “plugin”.

And this is the second “good thing” about this pattern. No methods. Every function capable of operating on the hidden state of the CallStream is a stand alone function. It is not a method. There are no methods. Just functions. No special “plugin” mechanism is needed. Everything that can be used as a StreamVisitor is a “plugin” in a traditional meaning of the term “plugin”.

But wait, there is more ?! And this makes me dizzy I think. We can go one step further in this decoupling “jamboree”. We can write a CallStream so that we even do not use function objects. We can aim for OO “nirvana”: just objects and messages. We can encapsulate everything inside CallStream. Let me show you this form of CallStream on the example above.

// CallStream pattern with no function objects
CallStream("selector")("find","div")("attr","A",1)("css","color", "#fff") ;
// calling chain with no functions

CallStream does not prescribe anything about types of arguments, of course. The form above would give us even more freedom and flexbility. Above is almost an “jQuery mini language”. Just strings. jQuery commands, vs functions (StreamVisitors) or methods on jQuery Meta Caller object.

This is the third good thing. CallStream allows for total encapsulation of operations on some state. Combined with stream of calls. And still in a controlled manner. Call stream actually does not have any state, it does not know nor it does care what call_handler does. Consider an (imaginary) SVG encapsulation :

// CallStream pattern for svg simple wrapper
// create svg canvas
var canvas = svgCallStream('svg width="5cm" height="4cm" viewBox="0 0 500 400"')
('polyline points="100,200 100,100"')
('polyline points="250,100 250,200"') ; // break here
// proceed somehwere else
canvas('polyline points="250,200 250,300"')
('path d="M100,200 C100,100 250,100 250,200 S400,300 400,200"')
('circle cx="100" cy="200" r="10"')
('circle cx="250" cy="200" r="10"') ;

No functions. Just a “language”. In this case we use a well defined , exsiting SVG syntax, plus CallStream, to deliver an non obtrusive javascript syntax which allows the user to concetrate on the SVG but still stay inside the javascript code. Minus, tiresome SVG XML syntax of course.

function svgCallStream ( canvas_declaration ) {
              // called once , at the call stream beginning
              initialize_svg_canvas( canvas_declaration ) ;
return function callStream () {
              // called each time
              handle_svg_calls( arguments ) ;
              return callStream;
          }
}

Here I have made a bit more realistic example and introduced one more attribute of this pattern : an Call Stream Conctructor. Which is kind-of-a interface constructor. With the same purpose as any other classical OO “constructor” : to provide intialization opportunity. An intial input to aid object creation and preparation. To do the above in a traditional way, we would need to have some traditional “object with methods” :

// traditional svg wrapper
// create svg canvas
var canvas = new Svg({ width:"5cm",  height : "4cm", viewBox:"0 0 500 400"});
canvas.polyline([100,200 100,100]) ;
canvas.polyline([250,100 250,200]) ;
canvas.path({ d : "M100,200 C100,100 250,100 250,200 S400,300 400,200"});
canvas.circle(100,200,10); //x,y,r
canvas.circle(250,200,10) ;


Summary

Perhaps I could formalize this meta-pattern in its (for the time being) final JavaScript shape.

// (c) 2010 by DBJ.ORG. MIT licence
// called once on the first call
function CallStreamConstructor ( ) {
          // pass initial arguements to the state
          CallStreamBridgeInitiator   ( arguments ) ;
     //  callers use this function for "call streaming" to the state behind
     return function CallStream () {
        // A bridge to the state behind
        CallStreamBridge  ( arguments ) ;
         return CallStream ;
     }
}

CallStream meta-pattern gives us additional degree of flexibility in composing concrete patterns and designs. By basing designs on this meta-pattern and cocnepts, we are comprehensively decoupled from “no-interface” issues, while still handling the underlying state effectively. CallStream is simply encapsulating pure interfacing activity. An simple yet powerfull mediator concept, that decouples users from implementations.

Also, it delivers method for brokering the calls between user and underlying state handler. In a totaly decoupled manner. Opposite of this, in every traditional objects-and-methods universe, interfacing mechanism and implementation is unfortunately interlaced with actual implementation of the logic of handling the object state.

Let me repeat once more : CallStream pattern decouples user from interface interface from implementation. It delivers the interface as a separate mediating entity. And. It provides an message based interface, with no methods ;)

Tagged on: ,

23 thoughts on “CallStream. An JavaScript Interfacing Pattern

  1. Balazs Endresz

    Interesting idea, let me reflect on some other aspects of this:

    First, I think calling this an interface pattern is slightly misleading, it’s more like sealing an object, where you can’t add methods to it any more (in case of passing strings). Of course, compared to prototypal code you can have much more control over the properties of the underlying object but on the other hand you can’t really extend it, only pass functions to it. For example, how would jQuery plugins look like without having a shared prototype object, where they can be organized?

    Moreover, you can use arbritary functions with prtotypal code as well with an extra helper method. A naive implementation in jQuery:

    $.fn.apply = function(fn){
      fn.call(this);
      return this;
    }
    

    where you can use the above like this:

    $().apply(function(){ this.toggle(); });
    

    What I like about your “callstream” pattern though, is that it indeed hides the logic of state management/mutation from the user, which might be a “good thing” in some use-cases.
    Speaking about state, you don’t even have an object here, but only functions, and when you assign a function to a variable, then unlike an object, it won’t create a reference but will rather create a copy of that function. This might have some performance implications. And you won’t be able to determine if two callstreams are the same (though I’m not sure if that would be meaningful at all), not to mention that since one might expect it to work as an object it could even lead to errors if not used accordingly.

    The last issue, which might need some more explanation as it’s a bit far reaching, is that you’ve actually created a new notation to write (sort of) monadic code in javascript:

    http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/
    http://labs.mudynamics.com/2009/05/13/monadic-parser-in-javascript/
    http://www.bluishcoder.co.nz/2007/10/javascript-parser-combinators.html

    The last two links above are two examples showing how this could have been done until now. Basically you could simulate Haskell’s “do notation” in javascript by creating an OO wrapper, where indeed, passing standalone functions isn’t quite comfortable. Or by passing higher order functions as arguments to a “sequence” function. So I think your “callstream pattern” might be a really nice alternative for these. Though I’m not sure I would use it in place of existing prototypal code :)

  2. Dusan Post author

    Thanks Balazs.

    First of all terminology is extremely important when inventing new patterns. “interface” is indeed an heavily and unfortunately overloaded term. Therefore, I think that I should use the word: Interfacing. So it is not a name any more, it is an Activity .

    This is dramaticaly different and I think (dramatically) better term, for describing the concept it is naming. As indeed, this is all about interfacing activity and/or communicating in a decoupled manner with some implementation which is behind a “CallStream”.

    Much lake communication through REST end points. Completely message based and decoupled from the server side components. Messaging system and concept but on the micro level, of the JavaScript programs.

    With CallStream “in mind”, I should obviously revisit my Moment := micro + component idea, and produce something more useable, than the sum of these two articles.

    Monadic point, you made is very interesting too. I shall try and engage in productive exchange of ideas with authors behind the links you provided.
    Also you said : “…Though I’m not sure I would use it in place of existing prototypal code…”
    Which renders me confused: what can be more “prototypal” than CallStream ;)

    –DBJ

  3. Bertrand Le Roy

    Very interesting idea and definitely true to JavaScript. You should submit that on Ajaxian to get more feedback and generally increase exposure of the idea.
    I was also confused by the “interfacing” name. Call stream is pretty clear on the other hand.
    The pattern is similar to jQuery’s each (with a terser syntax) or more accurately Balazs’ apply plug-in in the comment above. Ruby blocks are also kind of similar, as are some Lambda parameters in some C# patterns.
    But the syntax is definitely novel and fun. I liked the crazy CallStream()()()()()…
    I also like that it provides a non-plugin extensibility device.
    But I stopped agreeing when you replaced the function with strings: you would need something to handle the commands and removing functions also removes the main appeal of the pattern, which is frictionless extensibility.
    Plus, it then becomes a sort of DSL expressed in string form, and you’re losing a lot by doing that (ability to analyse the code, provide auto-completion, etc.)
    I’ll try to find a way to express the same idea in C#. Should be fun.

  4. HB

    Very interesting post. The “logger” example made me wonder, how would you introspect the current “stream”? For example, you might want to make a series of calls, then log the results all at once as the final call in the chain.

    Since (currently) each call returns the same CallStream object, is there a simple way to trace streams without affecting other streams?

  5. Scott Koon

    Nice, my first thought was “maybe you could nest calls to CallStream?”

    (CallStream(CallStream(“foo”, CallStream(1024, CallStream()))));

    Oh my, we ran smack into LISP again. ;)

  6. Dusan Post author

    @Bertrand : C# will be fun, especially using C#4 and its dynamic/functional extensions. Variant with strings instead of functions is just an example of the flexibility of this pattern. Heck, maybe I can, or should call it : “meta pattern”, since it obviously can be a base of the whole family of more concrete patterns.

    @HB : I think you dived into more concrete usability issues, which is good. Although I think “stream introspection” should be decoupled from a CallStream. As “anything” else. It is separate mechanism, that is functional but not part of the CallStream, and still serves the purpose. Remember: CallStream just dispatches the function arguments, one after another. Where and how and why is part of the concrete design and implementation. CallStream is just an meta pattern. A conceptual thinking framework for building concrete frameworks.

    @Scott K. : Ah, I have to admit now that I was “raised” on Auto Lisp. And some of it was non-trivial indeed ;)

  7. Pingback: Tweets that mention CallStream. An JavaScript Interfacing Pattern « DBJ.ORG -- Topsy.com

  8. Pingback: uberVU - social comments

  9. Fluxtah

    Nice, I guess you could also defer execution so you can do funky things like execute calls in reverse or randomly or by some interesting algorithm. :)

  10. Pingback: CallStream Part 2 : C# Binding « DBJ.ORG

  11. Balazs Endresz

    Maybe the most obvious application of this pattern is to implement currying in javascript:

    function curry(fn) {
      var args = [], length = fn.length;
      function CallStream() {
        args = args.concat([].slice.call(arguments));
        return length <= args.length ? fn.apply(null, args) : CallStream;
      }
      return CallStream;
    }
    //
    function add(x, y, z){
      return x + y + z;
    }
    // usage
    curry(add)(1, 2)(3);
    

    Of course, you can do this without a call stream as well but that’s a bit more complicated I think:

    function curry_old(fn){
      function ret(){
        var args = [].slice.call(arguments);
        return args.length >= fn.length ? fn.apply(null, args) : 
          function(){
            return ret.apply(null, args.concat([].slice.call(arguments)));
          }
      };
      return ret;
    };
    
  12. Dusan Post author

    @Balazs: I was always wondering do you understand your JavaScript potential ? Seriously. Your CallStream curry is great.

  13. Balazs Endresz

    Thanks, but the CallStream curry is actually wrong! Try this:

    var fn = curry(add);
    fn(1, 2);
    console.log(fn(3));

    var fn2 = curry_old(add);
    fn2(1, 2);
    console.log(fn2(3));

    What happens is that you call the same function twice, but with the callstream curry you have only one shared state where the variables are stored. So the functions behaves quite strangely, if you pass any parameters then all the other ones will receive it as well.

  14. Dusan Post author

    I can not see how do I post comments over there so I have to do it here, sorry ;)
    I would go even further with call-stream-enabling your parser. Example:

    var p = cs
     ("x", "<-", char_, "a")
     ("xs", "<-", optional, recurse)
     (ret, function(b){ return  b.xs ? [b.x, b.xs] : b.x })
    (run, "aaaaaa") ;
    /* 
    instead of :  run(p, "aaaaa"); 
    */
    

    I would implement “run” as an callback, to be “streamed in” too. Also correct me if I am wrong, or pushing my CallStream to much, but I think your “Usage” examples will look better with showing only call-stream enabled interfacing.

    Thanks for discovering yet another nice CallStream use-case …
    I wonder what would Bluish Coder , comment be ?

    –DBJ

  15. Balazs Endresz

    I’ve just added the callstream support today, and the examples were made before that. But I also like the look of the callstream parsers way much more.

    Adding `run` to the end would be possible, but that wouldn’t help one to compose multiple parsers.

  16. Dusan Post author

    Hm, yes, I myself am wondering (in general) about CallStream composition. Currently I think it is sovlable by “clever” state management in the “back”.
    For example (using your parser) one can imagine “parsing results” which are having id and which are saved and re-used by other parsing streams.

    //
    p1("one") ("x", "<-", char_, "a") ("xs", "<-", optional, recurse) (ret, function(b){ return  b.xs ? [b.x, b.xs] : b.x })(run, "aaaaaa") ;
    p2("two")( take, "one")("y", "->", long_ "x")(run, "bbb");
    //
    

    Above two parsing streams each have their own result storage named : “one” and “two”. Segment (take, "one"), loads storage “one” to be used by parser “two”.
    Something like this will work.

  17. Balazs Endresz

    Yes, that would be doable, but this is not the way you parse thing :)
    Usually you have only one string that you’d like to parse. But you compose the parser from smaller parsers: http://book.realworldhaskell.org/read/using-parsec.html

    var p1 = cs("x", "<-", char_, "a")
               ("xs", "<-", optional, recurse) 
               (ret, function(b){ return  b.xs ? [b.x, b.xs] : b.x });
    
    var p2 = cs(p1, ">>", many, char_("b"));
    
    run(p2, "aaaaaabbb")
    
    
  18. Dusan Post author

    Yes but ;) CallStream gives you the mechanism to hide/encapsulate “everything behind”. It forces you to conceptualize the state of your program and a “language” which operates on that state.
    It is best to imagine your solution “lives” somewhere in the cloud, and you can reach it only through CallStream-ing.
    I would do it perhaps in (something like) this way:

    // 'parsec' is an entity which has id
    // begin parsec "p1"
    parsec("p1")("x", "<-", char_, "a")
               ("xs", "<-", optional, recurse) 
               (ret, function(b){ return  b.xs ? [b.x, b.xs] : b.x });
    // begin parsec "p2"
    parsec("p2")( use("p1") , ">>", many, char_("b"));
    // restart parsec "p2"
    parsec("p2")( run, "aaaaaabbb") ;
    //
    

    Also. For some reason you do not use CallStream constructor as an opportunity for initialization? Also a CallStream Bridge as an device for decoupling call-streaming mechanism from the solution logic and from the state management. But still, your Parsec + CallStream idea I like.

  19. Balazs Endresz

    Well, I might implement this because it allows you to reference parsers that will be defined only later on, so you can’t refer to them by plain javascript variables (just by adding function wrappers). Other that it doesn’t make anything easier but this would be still a useful thing.

    Another use case is to keep the ParseState objects (which contain the string to be parsed, and the cache – see “packrat parsing”), so if you run a parser with the same string it could automatically reuse the stored ParseState object. But you rarely need this feature and the state can be saved manually as well.

    I don’t use it for initialization? Without this feature, why would I do it?

    The interesting part is that you can’t know which call will be the last, but if it receives a different type of argument, only then will it be evaluated (and cached). During that you can easily replace `use(“p1″)` with the actual parser, which can be even itself. The logic is pretty much decoupled I think, as this is just a layer on top of the do_ function and the operator resolution thing – it’s exactly what I needed to unite the two.

Leave a Reply

%d bloggers like this: