Re: Re: A preliminary stab at Flow-Based Programming

[Masem]

I do believe that FBP is a feasible goal; it does require more processor overhead and memory use than your typical procedural or OOP programming, and just like with those situations, FBP isn't a solution to all problems, only to a small subset. FBP also requires that the components are well designed with sufficient refactoring involved as to make sure most basic operations can be reconstructed with the right components. I think after a few more rounds of work, what I've got right now will start to look a little bit more interesting.

But while I've got matts ear... :-) One of the problems I had when putting the Merger together is that apparently SAX elements cannot tell whom sent the event or where the event is going. Because of how I set it up, the Merger SAX events were recieving events from two different streams at the same time due to how SAXT and the event tree worked. I had to use a somewhat icky hack for this (using

do { package DB; @callarr = caller(3); }; 
my @args = @DB::args;
my $sender = $args[0];

which is similar to code in Carp.) in order to id which dataset I was getting this from. Now, of course, on the way to work I thought of a better solution, possibly using closures, that would be able to connect multiple incoming streams at the same component, but I haven't tried to program this in yet. But in general, is there any other way of getting the sending of a SAX event while in a SAX event?

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important