[Python-3000] Abilities / Interfaces
Nestor
nestornissen at gmail.com
Wed Nov 22 02:38:11 CET 2006
On 11/21/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:06 PM 11/21/2006 -0800, Guido van Rossum wrote:
> >On 11/21/06, Nestor <nestornissen at gmail.com> wrote:
> > > Do these aproaches allow to do something like the
> > > java.util.RandomAccess interface that is just used as a marker?
> >
> >Zope interfaces certainly do. I don't know about Phillip's
> >counter-proposal.
>
> If we're basing GF's on types, then certainly marker mixins are feasible to
> *use*. I only contend that mixin markers (and other pure interfaces devoid
> of execution effect) are unnecessary and shouldn't be encouraged, not that
> they are or should be impossible.
>
>
> > With ABCs it would seem that one has to plan this
> >ahead of time (i.e., at class definition time), which isn't always
> >reasonable.
>
> For this reason, I would be against allowing *only* definition-time
> interface declarations. A major benefit of both adaptation and generic
> functions is that they allow retrofitting or gluing of "oblivious" code;
> i.e., code that wasn't originally designed to work with the thing you're
> gluing it to.
>
> Having only interfaces and introspection would also just mean that we are
> adding Java-like declarations and LBYLisms, without any improvements in
> expressive power or code clarity. Declaring an interface or adding a mixin
> should *do* something, instead of simply being a comment in the form of
> code, that other code is able to read. :)
>
>
I agree that interfaces instead of functions adds another level of
indirection for a mechanism that most of the time is used to signify
the presence of one or two methods. If the functionality of
dispatching on characteristics other than methods is worth adding to
Python I don't feel experienced enough to answer.
More information about the Python-3000
mailing list