>>9
I don't see any reason not to make them onymous; presumable the tile instances (or the classes themselves?) hold persistent references to the functions they need once created, so if you make them onymous now it should be easy to change them to a function hashtable or some such later.
Also, I don't think storing the functions themselves in a hashtable is that unconventional. It gives you a lot of power really easily; you can load them from separate files, you can have a drop-down console to edit them, etc. I suppose you can do that with onymous functions as well, but it doesn't seem as clean that way; with a hashtable you can easily dump the edited versions back out to disk for instance. Like a simple in-app IDE for editing your tile generators.
Reading
>>1 again, it seems you're actually generating these functions at runtime. So you're not persisting them? So my above advice is useless then.
Just what exactly is going on here? At runtime, during gameplay, you are somehow automatically generating functions that return tile image references (presumably from some sort of tile cache), and you'd like to not duplicate the instances of these functions as you generate them?
If that's the case, then just memoize the return values of your function generator. That's where your hashtable should be; wrap the generator in a simple function that checks the arguments against a hashtable. If it's not in there, run the generator, catch the return and drop it into the hashtable; if it is there, just return a reference to the function already in the hashtable. No need to name anything. This is of course assuming your function generator has no side effects, and has a single point of entry.
I'd recommend taking a step back and thinking more about what you're doing. This is way too fucking complicated. At least it has assuaged my withdrawl symptoms from lack of
/prog/ though, and I like the word "onymous". I wouldn't say no to a more in-depth explanation of your project.