One of the ideas I've been playing with in programming, --
I'm not sure what to call it really:
"Radical Overloading?"
"Radical Polymorphism?"
"Crazy Overloading?"
"DWIM Overloading?"
"Argument Intelligence?"
"Improvisational Argument Interpretation?" The idea is to really maximize "Be liberal in what you accept" as applied to argument interpretation.
Level 0: Conventional Argument Interpretation
foo(typeA argumentA,
typeB argumentB,
typeC argumentC);
- 1 signature, tightly defined
Level 1: Function Overloading foo(typeA argumentA,
typeB argumentB,
typeC argumentC); foo(typeD argumentD,
typeE argumentE);
- multiple signatures for the same function
- multiple arguments at the same slot
Level 2: Starting to get Crazy foo(typeA argumentA) foo(typeB argumentB) foo(typeC argumentC, *pos_args, **kw_args)
- multiple signatures for the same function
- ad hoc positional arguments
- keyword argument pairs interpreted dynamically by the function
Level 3: Very Crazy foo(*pos_args, **kw_args)
{
// initial code works at interpreting arguments dynamically,
// and may well call other functions in order to do it
}
"Lion, Lion -- too abstract -- what's this all about?" It's about being able to have these very high-level functions that you can just throw stuff at, and it automatically works. So for example, if you have "render_webpage," -- you should be able to send it:
- a string that is a pathname to a file
- a string that is fully formed html
- a string that is an html body
- a file object
- a string in some wiki markup language
- a dictionary with keys "title" and "body", and string values
- ...or the same dictionary, but the body being a file object
- some object that is an instance of a class that you made AFTER you wrote render_webpage, and that doesn't conform to a particular interface made to ease discovery
"Crazy, Lion!"
Yep, it's crazy. But I've been working on it, anyways.
It's just too much fun.
"So how do you do it?"
- Well, I have only implemented a little, but the strategy is as so:
- Recognize common patterns of "it should work like..."
- Write a library of code to support argument interpretation.
- Make the library extensible, so that the programmer can guide argument interpretation.
- Keep a database of synonyms and other human terms.
- So if somethings looking for a "title", but there's only a "name," the name can be used in place of the title.
The system knows that it's looking for a title, and didn't find it, so it starts scouring.
One of the interesting things that comes up is dynamic string subtype recognition. Q: "What's the type of that argument?" Oh, it's a string.
Q: "Yeah, but what KIND of string?
Is it XML? Is it a filepath? Is it a journal entry? Is it a URL? Is it a structured tree? Is it an index? What the heck is this string?"
So, I have a function that infers type information from a string.
Q: "What if I want it to be interpreted literally, as nothing more than a string?"
There's an argument for that.
That is, you can massage arguments with further arguments.
Presently, I have simple baby steps implemented: arg_as_bytes -- converts the input into bytes:
- file arg -> bytes of file
- string arg (filepath) -> bytes of the file
- string arg -> UTF-8 bytes
- bytes arg -> [identity function] multiline -- convert input to a single line
- file arg -> string content of file, UTF-8 decoded
- string arg (filepath) -> bytes of the file
- string arg -> [identity function]
- list of strings -> strings joined with newline char lines -- convert input to a series of lines
- file arg -> list of lines, UTF-8 decoded
- string arg (filepath) -> lines of file, UTF-8 decoded
- string arg -> lines of file, newline separated
- list of strings -> [identity function]
The dream is to be able to say: render_page("foo.txt")
...and get out something reasonable.
(Specifically, in this case, foo.txt as a text/plain,
provided that it doesn't contain XML content, or what have you.) render_page(body="foo.txt")
(Now it's an HTML body, with the title "foo.txt") render_page(body="foo.txt", title="My Favorite Title")
(HTML. If body is HTML or XML, inline it.
Otherwise, <pre>...</pre> after escape.) render_page(".")
(Directory index!) render_page("Hello, world!")
(An HTML page reading "Hello, world!")
"Crazy!" Yeah, I guess. But my limited experiment with arg_as_bytes, lines, and multiline is so successful, brings me so much pleasure, makes my life so much easier, that I'm tempted to run with this crazy thing I've been playing with. I'll report how it goes. {:)}=