Passing functions (closures) remotely might be an interesting feature to think through. Certainly it's been implemented at least in laboratory settings with systems like Kali and Termite (both based on Scheme and implemented with serializable continuations).
That's beyond my immediate interest, and presents some difficult problems beyond the current jini and javaspaces design. For one thing, it locks a specific solution into a Scala dependency. Moreover, a closure could be deliberately or accidentally capturing a fairly deep and complex object graph. The same is true of objects, and maybe this is just a matter of establishing design guidelines and tools. It could be at least a notational convenience, but Scala has a more concise notation even for classes. Food for thought. -Patrick On Mon, Oct 24, 2011 at 4:45 AM, De Groot, Cees <[email protected]> wrote: > Thanks for the rant, Dan - saves me a lot of typing :). > > It seems we have a generation of people that have been educated in software > development while being well shielded from a) the hardware, and b) anything > previously accomplished in the field. I've just started up a little project > to do HA and fast messaging, and people are surprised that I insist on > getting the HA bits right before even considering writing a single line of > code for the actual messaging/queueing, etcetera. But then, I've yet to see > one good product where HA (and scalablity, in various combinations) worked > when it was slapped on as an afterthought. > > The best thing that Jini/River has to teach us is to what extent remoting > needs to be transparent to the developer. Sadly enough, more than most people > are willing to put up with, but it's pretty hard to ignore basic facts of > your trade and still expect working outcomes. > > On the initial question: I'd love to see first-class bindings for Scala in > River (especially employing the function-as-a-first-class-citizen bit). > Sounds like a cool project (but then, I got the one I just started to > complete first ;-)).
