On Sat, Mar 14, 2009 at 9:32 AM, Terry Brown <[email protected]>wrote:
>
> Before I'm burned at the stake (this is only pretend, after all), I know
> clones bring enormous benefit. But I don't use them.
It's fine to revisit basic principles from time to time.
For example, the
> classic case of collecting nodes needing work in one place using
> clones. Using backlinks's approach you can do it two ways, either one
> node ("Active problems") with links to each of the things you're
> working on (which are displayed in the log panel currently, but could
> possibly be integrated into the tree),
>
or, if you want a place to make
> problem specific notes / track progress / etc., have a list of regular
> child nodes under the "Active problems" node, each with one link to the
> target node.
The great thing about clones is that they are regular part of the tree. In
most respects, nothing special needs to be done to handle them.
Creating "special cases" for (alternatives to) clones is not likely to bring
simplification or additional power.
Furthermore, the essence of the "clone problem" are clone links. It does
not seem to matter much how those links are represented; the problem is that
any link can break. We see this now with @auto.
>
>
> I prefer this to clones because I'm often collecting active problems
> from trees which represent projects, not software. Consequently the
> trees are often quite deep (compared to software), and using clones
> makes all the branches below the clone appear in the "Active problems"
> node list, where I don't want them. Fine as long as the node's
> collapsed, but when it's expanded you don't see the list, nor do you
> see the context of the tree surrounding the cloned node. Whereas the
> backlink style link just jumps you to the node in question in it's
> original context.
The request for "one-level" clones crops up from time to time. It's not an
outrageous request, but I don't know how to do it cleanly.
>
> I'm sure this is heresy, but I've felt "Whenever we start having fun,
> clones come along and spoil it" too.
Maybe, but clones are also Leo's defining feature.
> I would like to be able to have
> dynamic nodes in leo, such that leo doesn't store the nodes, but calls
> back to the application using leo to get child lists etc. This is
> another game I suspect clones would spoil :-)
Or, on the contrary, it might be the solution to clone problems. Let's keep
the possibilities open.
Computation is the typical alternative to static data. In many cases it is
much preferable to static data because there is no need to continually
update the data when other data changes. You could call this lazy
evaluation.
The problem with *all* schemes that distribute data (or computation) is
ensuring consistency of data. It's conceivable that Zope would form the
(conceptual and real) platform in which to address these issues.
It would be great, Terry, if you could come to Chicago with Kent and me :-)
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" 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/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
