> instead interfaces can be defined in terms of individual operations, and
> those operations can be initially defined by an abstract base, concrete
> class, or an "interface" object.
I think this is quite problematic in the sense that it will force many
dummy interfaces to be created. At least without type inference, this
is a no-no.
Consider: In order to type a function like:
def f(x):
# ...
x.foo()
# ...
...so that type violations can be detected before the real action
takes place, you would need to create a dummy interface as in:
interface XAsFUsesIt:
def foo():
pass
def f(x : XAsFUsesIt):
# ...
...or you would want type inference (which at compile time types x as
"a thing which has a 'nullary' foo() function) and a type system like
System CT.
Former appears cumbersome (as it should really be done for every
function), latter too NIMPY-ish <wink>. What am I missing?
Sleepingly yours,
Michael
On Wed, 12 Jan 2005 23:48:47 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote:
> >Regardless,
> >getting back to the main goal I had when writing PEP 246 -- your
> >alternative proposal still doesn't seem to provide a mechanism for
> >component developers to have a dialogue with one another to connect
> >components without involving the application programmer.
>
> Eh? You still have adapt(); you still have adapters. The only difference
> is that I've specified a way to not need "interfaces" - instead interfaces
> can be defined in terms of individual operations, and those operations can
> be initially defined by an abstract base, concrete class, or an "interface"
> object. Oh, and you don't have to write adapter *classes* - you write
> adapting *methods* for individual operations. This can be done by the
> original author of a class or by a third party -- just like with PEP 246.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
