[Jeremy Hylton]
>> ...
>> One of the key properties of C3 is local order is honored. If
>> a class A has two base classes B and C, then a method defined in B
>> (perhaps via their base classes) will be found in B first.
>>
>> This matches the way I think about inheritance, but not the way
>> the o
Jeremy Hylton wrote at 2003-11-24 14:06 -0500:
> ...
> One of the key properties of C3 is local order is honored. If
> a class A has two base classes B and C, then a method defined in B and C
> (perhaps via their base classes) will be found in B first.
>
> This matches the way I think abo
Note that this is moot, as I've decided to use a backward-compatible mro.
That is, new-style extension classes will use an mro that is backward
compatible with old-style extension classes. They do *not* use the same
mro algorithm as new-style classes.
Jim
Tres Seaver wrote:
On Mon, 2003-11-24 at
On Mon, 2003-11-24 at 12:03, Christian Heimes wrote:
> Sidnei da Silva wrote:
> > I'm going to fix those (after my english class) and then try something
> > harder ;)
>
> Here is more stuff:
>
> >>> import mrohell
> >>> base = mrohell.step1()
> >>> mrohell.step2(base, mroonly=True)
> Couldn't
On Mon, 24 Nov 2003 14:06:07 -0500
Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> [snip] Then programmers
> will be able to understand the code :-).
Very interesting conclusion... I might argue that it would be a premature optimization
however ;^)
-Casey
___
On Mon, 2003-11-24 at 13:22, Sidnei da Silva wrote:
> I think it was decided for the non-mro approach, though no one stated
> it clearly.
If it was, they sure didn't. A summary of the opinions that lead to the
decision would be nice.
Even if it's decided, it wouldn't hurt to fix the inheritance
I think it was decided for the non-mro approach, though no one stated
it clearly.
--
Sidnei da Silva <[EMAIL PROTECTED]>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher
I must have slipped a disk -- my pack hurts!
___
On Sat, Nov 01, 2003 at 09:10:11AM -0200, Sidnei da Silva wrote:
| Couldn't get mro for
| Products.GroupUserFolder.GroupUserFolder.GroupUserFolder
| Couldn't get mro for Products.CMFFormController.Script.FSPythonScript
| Couldn't get mro for
| Products.CMFFormController.FSControllerValidator.FSCon
Sorry, it was just on the wrong place.
[EMAIL PROTECTED]:~/src/zope/2_7-mro$ find . -name "*mroh*"
./mrohell.py
--
Sidnei da Silva <[EMAIL PROTECTED]>
dreamcatching :: making your dreams come true
http://awkly.org
The steady state of disks is full.
-- Ken Thompson
_
Not bad. On a 'stock' plone installation, i've got these results:
[EMAIL PROTECTED]:~/src/instance/mro$ ./bin/zopectl debug
Starting debugger (the name "app" is bound to the top-level Zope
object)
>>> import mrohell
>>> base = mrohell.step1()
>>> mrohell.step2(base, mroonly=True)
Couldn't get mro
On Fri, Oct 31, 2003 at 03:08:34PM -0500, Jim Fulton wrote:
| Sidnei da Silva wrote:
| >On Fri, Oct 31, 2003 at 02:39:28PM -0500, Jim Fulton wrote:
| >| I've checked the results of my work into the mro-advanture-branch (waa,
| >| I wish I cud spell) branch.
| >|
| >| You might find it entertaining
Sidnei da Silva wrote:
On Fri, Oct 31, 2003 at 02:39:28PM -0500, Jim Fulton wrote:
| I've checked the results of my work into the mro-advanture-branch (waa,
| I wish I cud spell) branch.
|
| You might find it entertaining to check out Zope on this branch:
|
| cvs co -rmro-advanture-branch Zope
On Fri, Oct 31, 2003 at 02:39:28PM -0500, Jim Fulton wrote:
| I've checked the results of my work into the mro-advanture-branch (waa,
| I wish I cud spell) branch.
|
| You might find it entertaining to check out Zope on this branch:
|
| cvs co -rmro-advanture-branch Zope
|
| (and build it) (No
13 matches
Mail list logo
