> > The idea of an interface has migrated to that of a "protocol" which > provides a ready namespace for a "record". >
A protocol is more than just an "interface by a different name" or an "interface+namespace". To understand the significance of a protocol, you need to first understand the "expression problem". The expression problem asks you to consider a set of polymorphic functions over multiple datatypes. Without controlling or being able to recompile the original source code, can you easily extend these functions to a new datatype, and can you easily create a new polymorphic function across those datatypes? Typically, OO languages make it easy to add a new datatype (just implement all the methods you want to implement for the new datatype), but hard to add a new method to an object whose source code you can't recompile. Typically, FP languages make it easy to add a new function (just take cases on the datatype in the body of the function), but no good way to add a new case for a new datatype to a function whose source code you can't recompile. Clojure has *two *clean, elegant solutions to the expression problem: protocols and multimethods. Protocols, for example, even let you implement your own new, custom "methods" on Java's built-in string datatype, which is what makes them far more powerful than interfaces. (Look up extend-protocol and extend-type for more info). Most languages don't have a solution to the expression problem. Some claim they have a solution because you can choose what sort of extensbility you are likely to need (am I more likely to add new datatypes or new functions?), and code accordingly using either an FP or OO approach. Python roughly falls into this category, but this is not a true solution to the expression problem. A true solution in Python involves writing your programs using the OO approach, and then google for "Python monkey patching" to look up tricks to inject new methods into classes you don't control -- it's possible, but generally frowned upon... not particularly good style in Python or a design principle we would want to teach students.
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
