stephen:
1) proc name collision avoidance
2) package consistency; i.e. pl/sql package named foo and tcl package named foo
3) ability to call procs by their real name from within a namespace; i.e. within namespace foo i can call function foo::bar by just saying bar, elsewhere i call it with foo::bar
ad_conn is meaningless, ad::conn is also meaningless. i am against putting names of people or companies in proc names. it only adds clutter and needless typing. if it's a matter of ego and recognition stick an @author doc tag in the ad_proc doc argument, which you should do anyway so that people know who to contact about a proc.
namespaces and proc names should be meaningful and should help categorize functionality. take as an example, the new permission:: namespace. newbies (and others) can very easily tell what this namespace is about and how to use it, check out http://yourserver/api-doc/procs-file-view?path=packages/acs-tcl/tcl/acs-permissions-procs.tcl, it's not the best documented package, but it's still fairly clear.
this brings me to another practice i think we should adopt everywhere. one of the reasons i created the new permission:: namespace is the use of named parameters. i think we should all use them everywhere. i have spent countless hours chasing down bugs all over openacs 4.x that boiled down to people passing arguments in the wrong order to functions. one of the common ones is ad_permission_p and it's siblings. this could have been much easier to find and fix (if not avoid all together) if the function had used named parameters. yes they are a longer to type, but i believe that is typing well spent. it helps with code self documentation and maintenance, it helps avoid situations like the one i explained above. i think we should make it a requirement for api's to use named parameters, and that we should slowly move the core to all named parameters, it's not that hard (of course changing acs service contract to use named parameters would be incredibly useful too).
i think those are enough reasons
