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:picolisp@software-lab.de?subject=Unsubscribe
