[erlang-questions] proposal: polymorphism by a protocol of convention

[Scott Parish]

Problem:

I've been writing several libraries lately, and trying to keep the
general purpose as possible. One example is a URI library. I'd like to
have a function that a user can pass a mapping of values, and it will
return a string fit to be used in a REST query (eg
"color=red&size=5"). The problem is that while writing this library,
users will only be able to pass in mapping types that i've forseen
allowing them to use. For instance, if i allow of tuple lists and
dicts, and the user is using gb_trees, he's got to convert it.

Thus people end up creating libraries that aren't as flexible as end
users may wish, or they have to specifically account for and handle
all the different permutations of types being passed in.

Solution:

First add a convention that any derived type should be enclosed in a
"record" (a tuple where the first value is an atom uniquely
identifying the name of the derived type)

Next, include code modules that identify different types of
interfaces. For instance, there could be a "map" module with method
such as "get", "put", "delete", "has". Calling the map module, it
would inspect the tuple passed in, and using the record name, call the
same named function on that module.

For instance, lets say i call: "map:put(size, 5, dict:new())".
map:put/3 will see that the "type" is "dict" and it will call
dict:put/3.

The above map module could also fall back on tuple-lists if a type is not found.

This should allow people to start writing code abstracted away from
the specific implimentation modules.

Thoughts?

sRp