[Zope-dev] Re: [Geeks] Interface Meta Data proposal

[Cees de Groot]

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