Hello Phillip,
> 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.
I don't see a reason to discourage them. It seems like a useful
pattern used in a few places in Zope 3, genuinely providing
additional value to the adaptation mechanism.
> 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.
Yes, late binding of interfaces to classes and instances is also of
real usage when using interface as markers, as it allows changing the
adaptation effect on uncontrolled classes and specific object instances.
> 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've lost you here. As I understand interfaces, their most important
feature is indeed being a "comment in the form of code", and I hope
they continue to be that way. What you do with them, being an
adaptation system like the Zope 3 component architecture, or even
generic functions with interface capabilities, is up to the framework
using them. Limiting a standard interface package to a given behavior
without these introspection features will only ensure that more
variants continue to exist and multiply. Having a standard interface
package will of course allow the interpreter itself to do decisions
about them ("doing something"), but it would be just one more user
of their intrinsic expressiveness.
--
Gustavo Niemeyer
http://niemeyer.net
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
