[GvR]
> > [SP]
> > *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.).
> >
> [snip]
> > 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
>
> As long as the slowness only applies when someone invokes
> SpamType.__foo__(x), that's acceptable.
Not that simple, *bad-guy-java* is really nasty given your design
for PEP 252 and PEP 253, you should put some hook to overridable behaviour
or completely give up with Java OOP ...
but it's our problem, your design
up to my mro concerns is clearly is sound.
But Jython 2.2 will be a major challenge.
Samuele.
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