difference in style
Things that cannot be converted to a string and back are usually the types of things that cannot be stored in a database. I'm thinking of open file connections, database connections, connection pools, procedure objects, semaphores, sockets, threads, mutexs, execution contexts, continuations, etc.
I suppose it depends on how the language works. In some langs/libs things like file connections and database connections were simply integers (ID's). The language kept a list (table?) of open "things". If there was a crash or shut-down, the list would be traversed and items closed.
I suppose in my ideal language and environment, EVERYTHING would be a table (surprise surprise). Thus, "complex structures" would be things like queries (strings) or ID's. Generally you reference the complex thing or service rather than pass it around as a RAM lump.
But tablisms aside, I don't generally find a need to put those kinds of things in named parameters for some reason. Named parameters are generally for "tweaks" rather than some complex structure by itself. I agree that arrays are more flexible, but like I said before, they are more wordy in calls. Given the tradeoffs, I would take less code. The few things that need complex RAM thingies down the road simply get a new fixed-position parameter, even if it requires finding and fixing existing calls. I doubt it would happen enough to justify more syntax. That is my weigh-in. Take it or leave it. (Assuming lack of real named params.)
________________
oop.ismad.com
