Thanks for asking. Yeah, I actually do. Certainly when I'm programming in C, I use plain old routines, 'cause that's all I got.
But recently I even "de-objectified" a body of Perl code I wrote (a standalone server called "loom" https://loom.cc/source).
I systematically refactored it to get rid of all $object->function constructs. I ended up with a flat name space with names like trans_get, trans_put, span_encrypt, diceware_passphrase, file_update, dttm_as_cookie, api_grid_move, valid_id, trimblanks, token_get, etc. etc.
I even have a little script in there called "show_subs" which lists all the routine names in alphabetical order. There are 410 of them.
You might call that a "polluted" name space, but to me it smells like clarity. I can now look at any snippet of code completely out of context and know exactly what it does.
You might say that the downside is that each piece of code is not "configurable", meaning that it can't operate on different types of things depending on context. If and when that ever became necessary, I could easily manage it. But I never found it to be necessary.
By the way, this discussion reminds me of this article posted earlier: http://erlang.org/pipermail/erlang-questions/2011-May/058769... . I look at the list of functions he exports there and I think yeah, I bet I could use those in a heartbeat without a second thought.
But recently I even "de-objectified" a body of Perl code I wrote (a standalone server called "loom" https://loom.cc/source).
I systematically refactored it to get rid of all $object->function constructs. I ended up with a flat name space with names like trans_get, trans_put, span_encrypt, diceware_passphrase, file_update, dttm_as_cookie, api_grid_move, valid_id, trimblanks, token_get, etc. etc.
I even have a little script in there called "show_subs" which lists all the routine names in alphabetical order. There are 410 of them.
You might call that a "polluted" name space, but to me it smells like clarity. I can now look at any snippet of code completely out of context and know exactly what it does.
You might say that the downside is that each piece of code is not "configurable", meaning that it can't operate on different types of things depending on context. If and when that ever became necessary, I could easily manage it. But I never found it to be necessary.
By the way, this discussion reminds me of this article posted earlier: http://erlang.org/pipermail/erlang-questions/2011-May/058769... . I look at the list of functions he exports there and I think yeah, I bet I could use those in a heartbeat without a second thought.