[GvR]
>
> > now A is in between list and object: what is the right thing here?
>
> Just say that this is what happens. The MRO is inconsistent in this
> case.
>
> > I don't expect or invite users to do that, but your rules allow A to
> > end up in that position in the mro, your philosophy seems to be
> > this is thin ice and so let it be ...
>
> Exactly.
I wish I would not feel uneasy with that <wink>
>
> On the third hand, if a C programmer *wants* to write a class with the
> proper cooperative super calling, they can do so, it's just a bit
> clumsy. Should I provide a C API to make this easier? I doubt that
> it will be used much. If there's demand, it can be added later.
I hope there will not be.
GvR> I don't think such subclasses
GvR> should be used in complex multiple inheritance lattices.
>
> > Better to enforce that?
>
> Why? I can think of situations where you have a MRO like this:
>
> C list B object
>
> but where B doesn't override anything that list might use. In fact,
> this is the typical mix-in situation. I don't want to forbid this.
OK, I see. (*)
GVR> So enforce it and see how it turns out in practice.
>
> > It's probably the best solution, at least for Jython,
> > and could even make sense for CPython (see above points)
>
> Good. We seem to agree.
Yup but I see your point (*) so probably I can't.
[me] *bad-guy-java*
> > > > Yes ... very slow and we would have to use that also at the very
> > > > core of the hierarchy, see (*) but the problem is more
> > > > complicated, in Java given three classes
> > > >
> > > > C extends B extends A
> > > > and a method m
> > > > C.m overrides B.m overrides A.m
> > > >
> > > > there is not direct way (even using reflection)
> > > > to apply B.m behaviour to a C object, unless
> > > > the programmer has left some hook in C using super
> > > > or in B ( a method B_m e.g.).
>
> I hope this discussion so far has been helpful -- I have to pack for
> my trip and will soon be off to San Francisco until next Wednesday.
>
Yes it was, thanks but
I overlooked a central point, namely *bad-guy-java*
I fear, because of it, we have to code all the built-in types this way,
class SpamType {
... SpamTypes__foo__ { ...
}
... __foo__ { }
}
Or find other slower ways, otherwise no descrs for them
A nightmare :-(
regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4