[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: abstracting Lisp strings - macro name convention?
From: |
Ken Raeburn |
Subject: |
Re: abstracting Lisp strings - macro name convention? |
Date: |
Tue, 02 Jul 2002 22:09:00 -0400 |
User-agent: |
Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) |
Richard Stallman <address@hidden> writes:
> SMBP is too terse. That won't be used so often
> that we cannot afford a longer and more meaningful name.
Okay, I'll use longer names. Probably something like this set:
STRING_DATA(obj) /* produces a char* */
STRING_REF(obj,index)
STRING_SET(obj,index,newbyteval)
STRING_INTERVALS(obj)
STRING_SET_INTERVALS(obj,interval)
STRING_NBYTES(obj) /* STRING_BYTES exists, takes Lisp_String ptr */
STRING_NCHARS(obj)
STRING_MULTIBYTE(obj) /* already present */
STRING_SET_UNIBYTE(obj) /* all uses of SET_STRING_BYTES are of the
form SET_STRING_BYTES(XSTRING(x),-1) */
And I'll remove or rename the macros operating on Lisp_String struct
pointers or with the terse names.
STRING_SET_BYTES(ptr,-1) -> STRING_SET_UNIBYTE(obj)
STRING_BYTES(ptr) -> STRING_NBYTES(obj)
XSTRING(obj)->foo -> STRING_foo(obj),STRING_SET_foo(obj,...)
SREF -> STRING_REF
SDATA -> STRING_DATA
etc
With a pervasive change like this, do you really want separate
checkins for each file and detailed function-level change log and CVS
log entries for everything affected? It's tedious, but doable; I'm
just unclear on how important you feel that level of detail is for
pervasive changes of such a simple nature. Occasionally other changes
have been checked in with log entries like "all callers changed"; most
(but not all) of them are for static functions, so it's still
describing changes confined to the one file.
Ken