ok, here's a recap:
1. All posix functions should be _moved_ to the POSIX module. That means: - they will not be available at their old, compatible location - old code which expects them at the old location will stop working
2. The functions moved in #1 can be aliased, in the compatibility mode, at their old locations thus removing the compatibility problem above.
3. The functions moved (as in the code sense and the namespace sense) to the POSIX module might be aliased from other spots in the namespace (like Math, for example) to make their location more logical from the usage standpoint. It can be done in the other directions - the functions code gets moved to, say, Math and it is aliased in the POSIX module.
The effect is that the functions are "physically" available in one module, the one named after the standard the functions are defined in (POSIX, WIN32, WIN64, BSD, whatever other standards we might find useful) and they are "virtually" available from other locations, which make more sense from the logical point of view. Now let's imagine a user migrating from C/C++ to Pike. They are used to use the manpages, they look at the chmod(2) manpage, and they read at the bottom:
CONFORMING TO The chmod call conforms to SVr4, SVID, POSIX, X/OPEN, 4.4BSD. SVr4 documents EINTR, ENOLINK and EMULTIHOP returns, but no ENOMEM. POSIX.1 does not document EFAULT, ENOMEM, ELOOP or EIO error conditions, or the macros S_IREAD, S_IWRITE and S_IEXEC.
They also read in the Pike docs that functions defined by the POSIX standard can be found in the POSIX module, so they know right away that they should use:
POSIX.chmod(...)
in their code.
Another scenario is where a programmer wants to use a math function. If the function is POSIX, they can use the above approach, but they can also read in the docs that the mathematical routines are found in the Math module, so they can use
Math.ceil(...)
Now, _where_ the functions are defined (in the source code sense) doesn't really matter from the programmer's POV, what matters is where they appear to them. Thus the proposition of the function aliases.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 17:36: Subject: argv[0]?
Sorry, but I can't make sense of what you write now.
My interest is not so much which functions that are added to a POSIX module, but which that are ___moved___ there, as in _copied_ and then _removed_(*) elsewhere. The only example you named that I agreed on in that regard is crypt. Then you said that you didn't want them removed elsewhere afterall, but now you again say that you want to _move_ them.
Believe me, I really do not intentionally try to misunderstand you or nitpick words here. You earlier said (8970535) that there would be compatibility issues with the POSIX module exactly because the functions added to it would be _moved_ there, which can only happen if they are removed(*) elsewhere. Then you said (8974606) that you never suggested that they should be removed(*). It's apparently a contradiction and not just a simple misunderstanding of what "move" means.
So what do you really mean? Should these example functions be removed outside the POSIX module or not? Note that whether they are left in compatibility mode or not is not the issue at all here (they obviously must be).
(And no, I don't expect a complete list. I never said so, but otoh I never said explicitly that I don't.)
*) Notwithstanding compatibility fixes that are activated with #pike or -V, of course.
/ Martin Stjernholm, Roxen IS