Eh, while we're doing this discussion of Leo architecture thing, here's a longish email I wrote the other day and didn't send...
On Wed, 25 Apr 2018 17:22:18 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote: > All comments welcome. I'm not sure this is a very valuable comment, and probably not very original either, I think these things have been said before. But... Clones are really expensive. Expensive in the Python 2/3 transition and string/bytes/unicode transition sense. They're always demanding extra dev. effort. So what are they worth? It seems they have two uses. 1) Creating alternate views of data within Leo, i.e. cff (clone-find-all-flattened) and its friends. 2) People often want to use them as a templating system, although I'm not sure this is a good use case, clearly they can bite, and trying to use them this way makes understanding the somewhat confusing rules for when they're safe really important. These templating applications inevitably lead to cross file clones. I understand the appeal to non-coders looking for authoring systems for websites etc., but I think they're even more double edged in this case than they are in use case (1) above. With enough motivation I think alternative solutions like UNLs / bookmarks / tags / backlinks could give the same workflow experience clones give in case (1), but unless there's an actual push for Leo without clones, I'm not sure the motivation exists. (1) is really really valuable, I'm just not convinced it requires clones. So this is really just a passing observation: Clones generate the need for @file. Ok, not really true and way overstated, but because flattened clone views remove context from nodes (whose __init__() is this?) nodes need verbose names like 'BaseEdit.editWidget' instead of 'editWidget'. The name itself isn't that big a deal, although I prefer not to see the visual clutter of 'BaseEdit' repeated on every head line. Deciding to use sentinels and the impact on collaboration *is* a big deal. You could use @clean instead, but in aggregate a lot of work went into generating all those annotated headlines - are you really comfortable keeping them in the .leo file and hoping no one reorganizes the external file in a way that invalidates them, or do you want the security of having them embedded in the source file as @file does, where they're under solid version control etc.? I'm not saying clones and what I suspect is their dependence on @file are a barrier to collaboration, you really can use @clean (or my favorite, @auto ;-) when you need to. Just that cff creates the need for verbose headlines which are most robust in @file. Cheers -Terry -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
