| Ooooohkay. If anyone has a problem, I'll send them to you and Sidnei. :)
/me takes his iBook and a plane to The Amazon
| Note that, in many cases, the people having problems will *not* be the
| product authors. They'll be people who just want to upgrade thier Zope
| installationa that use third-party products.
Most of the time, this is the same people who can't update their
products, so if they *do* want a new zope, they will need to get a new
product as well. I think its safe to make that assumption.
| Well, except that they are the same rules used for classic classes, which
| probably still predominate in the Python world.
That may be worth considering.
| > as opposed to a
| >short-term problem of updating existing code.
| It won't be that short term. It will come up each time someone wants to
| use a product that hasn't been converted before.
Considering that 2.8 may be at least 6-8 months in the future (is that
a nice assumption?) I would consider that a just-long-enough term.
| I don't think it makes the code any clearer. Zope 2 has an extremely
| complex inheritence graph. Changing the mro algorithm won't change that.
| Zope 3, of course, makes much less use of inheritence and has clearer
| code. It also uses new-style classes and, thus, uses the new algorithm.
Now *that* is a good point for going with the new algorithm. We don't
want to have even another round later on to make it compatible with
Zope 3. If we could do it at the same time it would be a
bonus. Though, from what I understand, your custom algorithm would
| I personally don't like the new algorithm, but I don't really care
| in the long run. One should avoid inheritence complex enough to show
| a difference.
I hearthly agree here.
Sidnei da Silva <[EMAIL PROTECTED]>
dreamcatching :: making your dreams come true
The trouble with computers is that they do what you tell them, not what
-- D. Cohen
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -