cc: [email protected] Subject: Re: Renaming .sh.sig.value.q and .sh.sig.value.Q to .sh.sig.value.int and .sh.sig.value.objrej? --------
> P.S.: I dislike the idea of renaming .sh.sig.int to .sh.sig.q. Its a > torture for people. Could you not just accept .sh.sig.int and > .sh.sig.objref, or stick with .sh.sig.int and.sh.sig.ptr? The name > "ptr" is used even by perl and python. > > The shell does not have pointers so ptr makes no sense. The fact that perl uses ptr is not a good argument. The shell is not perl and doesn't want to be perl. It provides a higher level of abstraction and does not try to be a C interpreter. You have to think of this from the point of view of the shell programmer that does not know C. Alll they know is that kill -q sends a signed integer, and kill -Q sends an unsigned large integer along with the signal. Unfortunately, the received doesn't know which of these was sent, and therefore has to display both. If I know, then the name would just be value. Therefore, I need names that will identify the value of sent with -q and the value sent with -Q. I could have used signint for -q and unsignint and -Q for unsigned int, but felt that q and Q were simpler and more descriptive. They don't repy on knowing the underlying C interface. Unless I hear a good reason, I am not likely to change it. I listended to earlier feedback about using the shell for intermediates between C programs and added -Q. At this point I don't know of better names for value.q and value.Q that would be better for non-C programmers to understand. David Korn [email protected] _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
