On Tue, Jul 8, 2014 at 10:53 AM, Edward K. Ream <edream...@gmail.com> wrote: > On Tue, Jul 8, 2014 at 10:24 AM, Kent Tenney <kten...@gmail.com> wrote: > > >> The persistence problem would be solved if the UAs were persistent. >> They would contain the primary key of the node, whether it is a gnx >> or something else. When I began I took this approach: creating a >> 'str_pgnx' key in the UA: persistent gnx. > > I see. Thanks for the clarification. > >> If the @auto node's UA contained a UA for each of the last seen >> nodes, their connection to the db would be maintained between >> sessions. > > There must be magic here. How does the @auto importer code know how > to associate any uA with any particular node?
If not true magic, some sleight of hand [-: One approach might be a hook within @auto trees which maintained a key/value store: hash(h+b) / node UA Added to the @auto parse/load would be code which checked if a particular hash(h+b) had been seen previously, if so, give it the corresponding UA > >> If the primary key attached to an @auto node was OTHER than the >> gnx, it would increase the potential for collaboration, since the 'user' >> component would not interfere. > > Ok. I don't care what the "key" is: it can be a gnx or anything else. > >>>> However, when working with source code, I consider the correct structure >>>> to be that provided by the language: declarations, functions, classes, >>>> methods ... exactly what @auto does, no more, no less. >>> >>> I disagree. You seem to be forgetting organizer nodes. >> >> An organizer node is what Leo uses to name a chunk, no? >> That's what I consider the correct degree of decomposition. > > An organizer node is a node that contains other nodes. For example: > > + myClass > - ctor > + getters > - getter1 > - getter2 > > At present, there is no way for @auto importers to recreate the node > called getters, nor to make getter1 and getter2 children of the > getters node. Ah, ok, you are right, I don't care about those kind of nodes. I think they might even be dangerous, facilitating code which is too big or complex. > > The @views work was a *very* complicated way of remembering. It > eventually became too complicated for me to stomach...Having said > that, I am willing to consider reviving the project... > > Edward > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to leo-editor+unsubscr...@googlegroups.com. > To post to this group, send email to leo-editor@googlegroups.com. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
