So it seems the OO came in handy, it is now possible to query an arbitrary amount of different Redis databases at the same time, host, port and key prefix are stored/encapsulated in each Redis instance.
The big new thing is the prefixing to avoid key conflicts between projects running on the same machine, it is a must have really. I've also added it to the ext library: https://bitbucket.org/hsarvell/ext/raw/fd41e8e8f43de04b6a46474809bc0c4099fa20b6/redis.l On Mon, Nov 26, 2012 at 9:42 AM, Henrik Sarvell <hsarv...@gmail.com> wrote: > I'm always keeping my options open so I don't have to rewrite a lot of > stuff later if I realize I need for instance encapsulation. > > > On Mon, Nov 26, 2012 at 9:21 AM, Thorsten Jolitz > <tjol...@googlemail.com>wrote: > >> Joe Bogner <joebog...@gmail.com> writes: >> >> Hi Henrik, Hi Joe, >> >> > Thank you for sharing. I have also thought about using redis for >> > session state. >> >> I find that quite interesting too. >> >> > I tend to use picolisp in more of a functional form possibly because >> > its a breath of fresh air after 10 years of oop in c#. I sometimes >> > wonder when its a good fit to mix in oop in picolisp. >> >> The last sentence addresses a question I have (or rather two question >> about one topic): >> >> Say I want to write a parser in PicoLisp that parses Org-mode files >> (with their outline tree structure) and stores the structure and >> contents of the file in persistent objects in a database, allowing to >> reconstruct the file on demand (and to query the content, recombine it, >> or to use it in a web-application). >> >> The tree-structure of the document could be represented naturally by a >> class hierarchy, and each element-class could not only store the >> elements content and meta-data, but also have specialised methods for >> parsing org-mode-elements of its type. So the main parser only would >> have to recognize an element-type, create a new object of this type, >> and call its parsing method that stores all the stuff inside the element >> as well as its meta-data in 'This. >> >> Questions: >> >> 1. Would that be a reasonable application of oop in PicoLisp? How does >> it compare to parse a wiki-file and store the nested elements in a >> nested list? >> >> The reason I would want oop is to allow for big data and to be able to >> quickly select/filter elements and to export them to some kind of >> thematic wiki-file (agenda files that show entries for dates, or topics, >> or certain tags etc. ) >> >> 2. What about version management in the database (without reinventing >> GIT or so)? >> >> Since Org-mode files are plain text, VC like Git is perfect to manage >> changes over time. What if such a text-file has been parsed and its >> content stored in a OO-PicoLisp DB - how would one deal with changes, >> updates, keeping history without starting to write its own version >> control system? Simpy check if the original text-file has changed, and >> if so, parse it again and replace the content in the already existing >> objects? >> >> Or is there a smarter way that minimizes parsing and stores only the >> diffs, keeping the history somehow? >> >> -- >> cheers, >> Thorsten >> >> -- >> UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe >> > >