Just finished working on it. I made a few changes (minor), like passing through the zone and getting rid of unnecessary globals and all that. The more I look at it, the more I like it. Esp the comm2func transition. This will definitely simplify things for us. Thanks for this excellent suggestion!
Cheers, Dan On Fri, Sep 25, 2009 at 9:37 AM, The Editor <[email protected]> wrote: > On Fri, Sep 25, 2009 at 4:57 AM, DrunkenMonk <[email protected]> wrote: >> >> On Sep 24, 4:49 pm, The Editor <[email protected]> wrote: >>> DM, I have no problem doing this but I'm not 100% sure I see the >>> advantage. Can you tell me exactly what this does for you? >> >> It stops Boltwire having to construct a string only to deconstruct it >> again. So anything that isnt text input from the start but needs to >> call a function can do so faster and with less problems. > >> It also bypasses the problem of having to escape single-qoutes in >> comm2func entirely. > > I see. So comm2func would be able to delete these lines > > $value = ''; > foreach($args as $f => $v) $value .= "$f='" . > str_replace(Array("'", > '"'), Array(''', '"'), $v) . "' "; > > and the last line would go to BOLTfunc, rather than BOLTMfunc. That > is a nice improvement. Very nice. > >>> I suppose breaking down functions is a good choice--gives more >>> granularity. But shouldn't we put toolmapping and translation into the >>> BOLTMfunc? And leave BOLTfunc for just raw output handling? >> >> I see markup as "taking a string and outputing something boltwire can >> understand" wheres as engine should be "anything boltwire does". So I >> think the logical choice would be the divide I suggested. >> >> Consider someone making a plugin in, say, chinese, and wanting to tap >> into another boltwire function, like search. They don't want to have >> to construct a string like in BOLTMfunc, but they do want to haave >> access to translation and output. The logical thing to do would be to >> call > > I got it. Though they could use toolmapping to get a chinese word for > search, the parameters would still have to be in English. A real > chinese search function could take chinese parameters, reword them > into English and then send over to BOLTfunc. Of course, then you > wouldn't need the translation and/or toolmapping options. > > Aren't those part of the "markup" functionality--getting something > translated/mapped, into a function BoltWire can understand? > > On the other hand, I've come to appreciate keeping options as far up > the chain as possible. It always maximizes possibilities. So I'll go > with your suggestion. Just thinking out loud together. > > Cheers, > Dan > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
