* Olaf :: > On 6/13/05, Humberto Massa Guimarăes <[EMAIL PROTECTED]> > wrote: > > Yes, and I withdraw :-) what I said about XML. But *any* > > serialization / deserialization necessary for this scheme to > > work would add (unnecessary) overhead. This and the fact that > > you would > > Well, if you can do it with Perl without overhead, you can of > course also do it without Perl without overhead. In that case the > 'structured' support would be included
Not exactly. Don't get me wrong, object component technology is a great thing, standing just next to sliced bread in the list of great things, but (just like sliced bread) it does not cure cancer. When I do my example inside of Perl, I am supposing whatever objects or handles the Perl interpreter has stay inside the interpreter's process; when you do a pipe like monad-ls *.ab | monad-fields name, size | monad-tableout you are implying the existence of 3 processes, two of them making serialization of their (internal) objects for output, two or them making de-serialization of their inputs to (internal) objects, all of them analyzing (or receiving a hint from the shell, that had to analyze for them all) to see if their input came from an object pipe and if their output goes to an object pipe. At least two of those process have to read all of their input to memory before spitting any output (ls -- because it sorts the filenames -- and tableout -- because it dimensions the columns beautifully). This is a *lot* of overhead -- normal overhead, contention overhead (ls blocks the other two processes until it starts spitting its output), and synch overhead (any object read in the input must be perfectly synchronized to be a valid IPC object), and it's a lot of overhead independently of the IPC mechanism utilized. In the case of my Perl example, verbosely made to use a hypotetical text::table: use Text::Table; $t=new Text::Table; $t->addline($_, -s $_) for <*.ab>; print $t->as_text You still have some contention inherent to the operation you want to convey (sorting *.ab, determining optimal column width), but none of the (really expensive) freeze-serialize/deserialize-thaw cycles the monad version has, nor the (expensive, complex, and even with security implications(*)) input-format, input-synch, etc issues. (*) security implications because when you make a pipe component like monad-fields that can receive an arbitrary object as its input, you have to have in mind that said object can have security bugs in its methods, either on purpose or not. Imagine a malicious-ls that spits objects whose "get-name" method (property getter) copies the .ssh directory of the current user to another, publically-readable locale. This can be installed in someplace in the net and you can convince people that your ls is better and 0wn the poor bastards... This *will* certainly happen in an environment like this because, well, there will be a point in time where it will be too much trouble to check all those distributed objects... Not unlike a lot of websites install spyware via ActiveX in the poor IE-using folk. -- HTH, Massa
