> That's only if you do it as a property. It doesn't have to be done that > way. Shane and I discussed a counter that existed as a central > datastructure. Objects that were being counted would simply have > methods to increment the count and display the count.
FWIW, this already mostly exists in Zope as the (tiny) BTrees.Length.Length class. It's a awfully nifty little piece of code. Anybody who is interested should read it and try to understand it because it's subtly mindbending and ingenious and it is a prime example of why we love Jim. ;-) > Completely agreed. My disagreement is portraying the counter problem as > impossible with the zodb. I think some people, as evidenced by some of > the responses, are willing to live with the tradeoffs. Other people > will find managing a log file on disk to be a more manageable solution. It would be best to make make a dual-mode undoing and nonundoing storage on a per-object basis. But a half step would be to make it easier to use mounted storages ala http://dev.zope.org/Wikis/DevSite/Proposals/StorageAndConnectionTypeRegistri es. _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
