My problem with the obvious solution to my unexposed types problem

November 8, 2009

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)

(Both parse_stream and 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 versions of 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.)

Written on 08 November 2009.
« Solving unexposed types and the limits of duck typing
HTML5 may end up giving us real, working XHTML »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 8 23:26:12 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.