Phillip J. Eby wrote: > In essence, interfaces turn libraries into "frameworks", but generic > functions turn frameworks into libraries. I didn't really discover > this until January of last year, though, when I did some experiments > in replacing various PEAK interfaces with generic functions.
This is easily the most important part of the conversation, IMO, and I would hate for it to be missed. "Interfaces" in the Java universe are a hard contract that everyone has to agree upon up-front, and if you don't agree, you have to create your own framework that does the very same things in a different way. What you end up with is a world of many competing frameworks, none of which interoperate. The alternative may not be as *familiar* but it certainly paints a much brighter picture. If you have two different frameworks that take slightly different approaches (or even _radically_ different approaches) to the same problems, you can make them work together as one, rather than having to pick one or the other. Its like framework detente! Adopting Java-like interfaces just because they are "familiar" would be a huge mistake, as it would condemn Python to the limitations of such an implementation unnecessarily. This is Python 3000, not Java, and while I certainly understand the argument of familiarity, I won't let something that seems a tad magical at first scare me into a comfortable decision. I have actually used generic functions (using RuleDispatch) in practice and find them to not only be hugely powerful, but much more pragmatic. Am I the only one out there who sees it this way? -- Jonathan LaCour http://cleverdevil.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
