Jeffrey P Shell <jeffrey@Digicool.com> said:
But I'm not sure how one would go about setting your meta-data in a way that is at all natural to Python. I think that exceptions that a method must\should raise *should* be part of a signature\contract. This is one of the really cool things about Java. If you use a method, 'readFile' that says it raises IOError, you *HAVE* to catch that exception (I believe in order to compile).
It's so cool, it really chills your productivity. The moment that Python starts doing that, I'll drop the language like a hot iron. 'Nuff about thermodynamics. Making exceptions statically checked is probably the worst misfeature of Java. The idea is nice, in that it forces you to deal with exceptions, but in reality it gets in the way too soon - when you're still exploring, refactoring, stuff like that you should be able to turn the damn things off. I've got five years of full-time Java programming behind me, so I know what I'm talking about.
But it looks like what you're really wanting is to use interfaces for documentation purposes, not for contract purposes. Not for interfaces at this level of the language.
Useful documentation, especially contracts, can be useful programmatically so stuff like that should at least be setup so that it is possible to move it into the language. A bit like the @pre and @post tags in Javadoc comments - they're always nice to have as documentation, but when you run iContract over them, they are activated and start checking your code's behavior.
If you don't say you implement 'Cloneable', an exception gets raised (even if you implement the proper method).
Another wart in Java that is nice in theory, but sits in your way in practice. I greatly prefer the Smalltalk "protocols" approach, where implementing an interface is accomplished by implementing the right methods period. The funny thing is, hardly any Smalltalk code ever checks for the interface: the (correct) assumption is that if you hand something over to some other thing that says it wants to iterate over whatever you handed over, you'd better be sure that the thing behaves at least enough like a collection so that it can be iterated over. That's the caller's responsibility (a sort of implicit precondition), and if the caller sends over something else, you get a DoesNotUnderstand exception. Very often I have longed in Java for the possibility of an object to implement a subset of behavior of another object, but that's not possible. For example, if you have a bunch of field labels you stuff in a collection just to be able to do getText()/setText() on them (say for internationalization). Now, I want to add menu labels to that collection, they also have getText()/setText() so they would be good citizens in that collection. Java does not allow that, unless I'm prepared to jump through instanceof/type casting hoops (which is only possible if I'm the one actually calling getText()/setText()).
This is similar to how we sniff things today, but we just do things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):'
The usual answer of an OO guru here is that if statements are considered harmful, and that if statements that check object types are considered very harmful. The modern variant is "these are strong refactoring smells". -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B