The Artima Developer Community
Sponsored Link

Weblogs Forum
Interfaces or Abstract Base Classes?

42 replies on 3 pages. Most recent reply: Dec 16, 2005 4:16 PM by Ed Suominen

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 42 replies on 3 pages [ « | 1 2 3 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:10 PM
Reply to this message Reply
Advertisement
interfaces just don't lend themselves to a dynamic language like Python
It's difficult to think past the notion of interfaces embodied in Java. Here's an implementation of interfaces for a dynamic language, Smalltalk:

Adding Dynamic Interfaces to Smalltalk
http://www.jot.fm/issues/issue_2002_05/article1

Perhaps reading that article will lead to a new perspective.

Jonathan LaCour

Posts: 6
Nickname: jlacour
Registered: Dec, 2004

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:13 PM
Reply to this message Reply
> Yes, but it is machine readable documentation that is a
> nice formal contract that can be verified absolutely.
>
> Runtime typing and duck typing are flexible. But, they
> can also lead to a lot of extra work in test development,
> to do things that a static typing compiler already
> provides the ability to do. The static typing compiler
> gets written once so everyone can use its built in testing
> facilities.
>
> An interface is a compile time test!

You should be using Java or C#. Python is clearly not for you. If you worry about "compile time tests" and "nice formal contracts" then run, don't walk, back to the security of a language like Java or C#.

The compiler only catches errors that can be found and fixed very quickly by a competent programmer. This is always one of the worst arguments that I have heard for interfaces. Formal contracts aren't what Python is about.

Doug Winter

Posts: 3
Nickname: winjer
Registered: Oct, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:16 PM
Reply to this message Reply
What about adaptation? Interfaces on their own are just documentation sugar really, but with adaptation they get a useful life of their own. So, how about a standard adaptation system too?

Jonathan LaCour

Posts: 6
Nickname: jlacour
Registered: Dec, 2004

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:22 PM
Reply to this message Reply
> What about adaptation? Interfaces on their own are just
> documentation sugar really, but with adaptation they get a
> useful life of their own. So, how about a standard
> adaptation system too?

I would much prefer to see a standard Pythonic adaptation system that *DOESNT* use interfaces than having interfaces for no justified reason.

I still contend that interfaces cannot be the only way to do adaptation, and they may not even be the best way. Give the folks on python-dev a chance to think about the problem, and I am betting that something good could come out of it.

Not to knock the hard work of another person, but I find PyProtocols, which is an interface/adaptation system for Python, to be very cumbersome and difficult to use, largely *because* of the interfaces portion. I know that someone can do better than this if they are willing to consider something *other* than interfaces as the basis for the system.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:27 PM
Reply to this message Reply
> To Everyone who thinks Interfaces must mean Static
> Typing: This is simply false.

Yes, exactly. But IMO this is the reason why interfaces in Python would be pretentious.

> Interfaces in Python are more of an
> adaptation (pun!) of the interfaces in other languages,
> like Java and Obj-C, than the original ideas themselves.
> Python's duck typing is about as dynamic a typing system
> as you can get. So much so that it is really more of a
> lack of a typing system than anything else.
>
> A lot of people are commenting, both here and elsewhere,
> that interfaces are little more than documentation.
> Perhaps, but if this is true, then you must look at the
> form of the documentation: it is machine readable, unlike
> human language. It is documentation to the runtime (they
> are dynamic, not static) that allows a more
> reliable way to identify what an object is capable of.

Is it? You can't say anything certain about an object within a Python runtime only because the class used to create the object implements a certain interface. The reason for this is the presence of __setattr__ and __delattr__.
So there is not much use to attach interfaces to classes due to Pythons object model. Their only reliable use is that of a filter for statefull objects ( after passing the filter the object may change it's interface in an arbitrary manner ). This may be fine for some people but I would like to see some convincing use cases. If interfaces were used nevertheless in projects like Zope or Twisted they might work because the team agrees about some conventions dealing with classes implementing them.

> Most importantly is the adaptation this allows, as the
> adaptation registry needs to know what all the objects can
> do, to make them do what you want them to do.

Well, I don't seem to have the capacity to understand this but maybe Guidos blog forum might not be the place to discuss your "design pattern" in detail.

Kay

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:48 PM
Reply to this message Reply
> > An interface is a compile time test!
>
> You should be using Java or C#. Python is clearly not for
> you. If you worry about "compile time tests" and "nice
> formal contracts" then run, don't walk, back to the
> security of a language like Java or C#.

I am not a python user. I am only watching this discussion to see what arguments python users have for another form of formal agreement about programming interfaces. A lot of the arguments for dynamic typing revolve around delayed binding. Delayed binding provides a lot of flexability in when you finally bind an action to some data. There are things that I think are great to delay the binding of. But, my preference is to draw the line at interface vs implementation. I prefer to defer the decision of which implementation to use, but formalize the semantics and bind the typing via an interface.

What duck typing and/or lack of interfaces drive, is a lack of commitment. Instead, informal arrangements and thus peoples attention to details provide the level of success that will be possible. More attentive people are more successful with dynamic languages. When I step away from a dynamic language project, it is very difficult to wrap ones head back around all the details without having to read a bunch of potentially unimportant documentation, to make sure that you understand the semantics and typing that is in place so that you can make sure that you don't break some things subtley.

Interfaces that are compile time checked provide an extremely powerful mechanism for guiding your attention to the correct details and to enforcing the contract(s) that the software was originally designed with. Interface validation at runtime, can at least provide a way for a dynamically typed language to include binary documentation of the contract(s) so that they can be analyzed.

What I did 10 years ago in a dynamic language that I created, was to add a 'isTyped' flag to variables that were declared with explicit types. The runtime, would see this flag on assignment, and make sure typing was enforced.

So you could type some arguments to functions, and not others, and as the arguments were brought into the function from the stack, they were assigned to the local parameter namespace and at that moment, they were type checked.

Thus, duck typing worked, no typing worked, and if you had a problem with a particular function needing to change typing, you could explicitly declare it, and then the users of that function would get a more specific error message during testing that would push them to the documentation, to see the API change.

Compile time checking makes this happen sooner, rather than at test time. But, if you can't commit to a type until runtime...

> The compiler only catches errors that can be found and
> fixed very quickly by a competent programmer. This is
> always one of the worst arguments that I have heard for
> interfaces. Formal contracts aren't what Python is about.

Well, without trying to be harsh, you have to commit at some point. There has to be enough semantic meaning in the implementation, and enough requrements from the users perspective that you can say "these things must hold".

Typing and interfaces with typing let you state these facts as unchangeable by the users.

I know it's really cool to see how many arcane things you can make a piece of code do by passing it an object different than what it was designed to run with. But, I don't consider this to be a desireable behavior for programmers in production environments. There are some things that have to work as advertised. Letting a formal, tool recognize contract be created for these types of things, seems like a natural decision. Might it remove some flexibility from you, perhaps, but I think that only a poorly designed interface would do that. And people who design poor interfaces are also the ones that will design poor implementations that also restrict or remove a feature that you need.

Calvin Mathew Spealman

Posts: 13
Nickname: ironfroggy
Registered: Aug, 2005

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 1:50 PM
Reply to this message Reply
> An interface is a compile time test!

Interfaces, like pretty much everything in Python, are handled at runtime. This is the most important aspect of interfaces in Python, because it alleviates most of the complaints people have about adding static types to python, which this does not do.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 2:11 PM
Reply to this message Reply
> > An interface is a compile time test!
>
> Interfaces, like pretty much everything in Python, are
> handled at runtime. This is the most important aspect of
> interfaces in Python, because it alleviates most of the
> complaints people have about adding static types to
> python, which this does not do.

I would have been better if I had typed:

In many languages that have interfaces, an interface is a compile time test!

Laurent Szyster

Posts: 4
Nickname: lavs
Registered: Aug, 2005

Re: Interfaces or Abstract Base Classes? Posted: Aug 8, 2005 3:37 PM
Reply to this message Reply
> But it seems that at least two of the largest 3rd party
> projects in Python (Zope and Twisted) have already decided
> that they can't live without interfaces, and have created
> their own implementation. From this I conclude that there's
> a real need.

Yes there is a real need for "interfaces".

But the interfaces required and implemented so far in Python are *component* interfaces. Application *hosts* like Twisted or Zope need those to provide its application developpers with a model for component integration.

Python itself, as a programming language, does not IMHO need a Java-like interface syntax.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Interfaces or Abstract Base Classes? Posted: Aug 9, 2005 1:04 AM
Reply to this message Reply
> interfaces just don't lend themselves to a dynamic
> language like Python

> It's difficult to think past the notion of interfaces
> embodied in Java. Here's an implementation of
> interfaces for a dynamic language, Smalltalk:
>
> Adding Dynamic Interfaces to Smalltalk
> http://www.jot.fm/issues/issue_2002_05/article1
>
> Perhaps reading that article will lead to a new
> perspective.

Looks like my latest musings about interfaces some months ago: on some easy weekend I took some LSD and each interface growed into heterarchic spirals and got incredibly rythmic and dynamic. It was a great experience. Unfortunatly I couldn't say the next day what it was good for. I had the solution but no problem anymore.

Kay

Brett C.

Posts: 4
Nickname: drifty
Registered: Jan, 2005

Re: Interfaces or Abstract Base Classes? Posted: Aug 9, 2005 12:40 PM
Reply to this message Reply
I just want to say that I used this syntax to specify the interface for a binding of a good -sized C++ library and it worked out rather nicely.

-Brett

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 9, 2005 3:26 PM
Reply to this message Reply
>there are many benefits to having interfaces. One of the primary benefits is in the use of RMI for remote access to services. Having an interface means that a small amount of code is shared by all to document how the systems work together.

--

You don't need interfaces for RMI. You don't even need different classes for proxies if you have a language that is inherently message based and loosely coupled where each object acts like a nano-server. I'm speaking of languages like Smalltalk and Objective C.

Objective C, BTW, has something like interfaces called protocols. I believe they inspired interfaces in Java. Protocols are useful for documenting interactions and for doing efficient runtime checking via something like conformsToProtocol:

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Neither - Traits Posted: Aug 9, 2005 3:32 PM
Reply to this message Reply
If you want to do something new and cool along these lines, please consider adding traits to Python.

http://www.cse.ogi.edu/%7Eblack/publications/TR_CSE_02-012.pdf

Otherwise you're just doing another me-too feature and I can't get excited about that at all.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Interfaces or Abstract Base Classes? Posted: Aug 9, 2005 4:04 PM
Reply to this message Reply
> >there are many benefits to having interfaces. One of the
> primary benefits is in the use of RMI for remote access to
> services. Having an interface means that a small amount of
> code is shared by all to document how the systems work
> together.
>
> You don't need interfaces for RMI. You don't even need
> different classes for proxies if you have a language that
> is inherently message based and loosely coupled where each
> object acts like a nano-server. I'm speaking of languages
> like Smalltalk and Objective C.

At some level, there is an agreement on the exchange that the two parts will have. That is what interfaces cover in Java. That name, brings about different views from different people/perspectives. In python, there are several issues that make the name interface less meaningful. But, in the end, I think having a documented specification of the exchange that is enforced by the language platform at either compilation or runtime, is helpful. Is it the be-all end-all of helpful tools, no...

> Objective C, BTW, has something like interfaces called
> protocols. I believe they inspired interfaces in Java.
> Protocols are useful for documenting interactions and for
> r doing efficient runtime checking via something like
> conformsToProtocol:

I have heard this as well... Regardless, the use of interfaces in Java is a language specific feature that makes sense in the Java environment. In Python, a different name might make sense, but I believe that a formal agreement is a benefit for external access to applications.

Phillip J. Eby

Posts: 28
Nickname: pje
Registered: Dec, 2004

Re: Interfaces or Abstract Base Classes? Posted: Aug 14, 2005 3:04 PM
Reply to this message Reply
> Not to knock the hard work of another person, but I find
> PyProtocols, which is an interface/adaptation system for
> Python, to be very cumbersome and difficult to use,
> largely *because* of the interfaces portion. I know that
> someone can do better than this if they are willing to
> consider something *other* than interfaces as the basis
> for the system.

Yep. That's why I developed generic functions and the concept of Monkey Typing, which use *operations* as the fundamental concept, rather than interfaces. Alas, Guido considers Monkey Typing to be more complex than interfaces and his type signature stuff, even though it's actually quite a bit simpler. (The implementation is probably of equal complexity to his typing ideas.) Unfortunately, a complete explanation of the theory involved in monkey typing is necessarily complex.

The idea of monkey typing is that you can define the notion of "file-like" by saying that some method of one type is "like" some method of another. Or, at a higher level, you can simply say that one class is "like" another, in the sense that any of its methods with the same names are "like" the methods in the other class.

Or to put it another way, monkey typing is simply a slightly more explicit form of duck typing, in that it requires you to somewhere say what your "walk" method is "like" Duck.walk, or that at least you are "like" a Duck. The same concept can be used to safely subsume adaptation.

Monkey typing also fixes one of the obvious problems with the proposed "file" interface: optional methods or attributes, leading to partial implementations of interfaces. In monkey typing, the unit of declaration is a method or attribute, not an entire interface.

For my own personal purposes, however, I find that extensible generic functions are a better solution than interfaces for most practical problems. Python in fact uses extensible generic functions for many purposes already: copy() and pickle(), for example. If such generic functions were first-class entities in Python, we could use concepts like 'file.read(ob, bytecount)' to do "file reading" on someob, rather than guessing at the semantics of ob.read. But it requires rethinking one's approach to OO.

Thus, I created Monkey Typing as a way to use extensible generic functions by masquerading them as "like" declarations and automatic adaptation, in the context of Guido's type declaration syntax. Also, Monkey Typing solves the problem of extracting interfaces (and therefore generic functions) from *existing* code, which no other solution (generic functions included) can accomplish.

Monkey typing, however, is dependent on type declarations in order to be most effective, which is why I personally prefer to use generic functions where I can, and more primitive techniques where I must. However, if/when Python grows type declarations, I'll certainly work on a monkey typing implementation for it.

Flat View: This topic has 42 replies on 3 pages [ « | 1  2  3 | » ]
Topic: What C++ Does Wrong Previous Topic   Next Topic Topic: Vlists, Stacks and Hash-Tables


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us