My problem with the obvious solution to my unexposed types problem
In my last entry about solving my unexposed types problem, I sort of cheated; I left out one obvious solution. My problem was that I wanted to have a function with 'polymorphic arguments', one that could take either strings or compiled regular expressions and then tell them apart.
Well, you know, one obvious solution is to not have such a crazy interface in the first place. A clearer, simpler approach would be to have two separate functions, one that takes compiled regular expressions and a second one that takes strings (and then compiles them and probably calls the first function to do the actual work). Instead of trying to wedge two interfaces into one function, we just have one function per interface.
In my view, the problem is that this doesn't scale; multiplying functions this way in order to multiply your interfaces breeds, sometimes explosively, because you also need to multiply any higher-level interfaces to these functions. Let me illustrate what I mean by way of my specific case.
My case looks something like this:
def parse_stream(fp, matchlist): ... def parse_cmd(cmd, matchlist): fp = os.popen(cmd, "r") return parse_stream(fp, matchlist)
parse_cmd are official interfaces, but I
expect to use
parse_cmd more often.)
If I split
parse_stream into two functions, I must also create two
parse_cmd, and if I had even higher level interfaces I'd
have to split those too, and so on.
(The other way that this approach can compound is if you have functions that are polymorphic on more than one argument. But I'm not sure that that's at all a sensible interface to start with; at some point it has to get too confusing.)