Compatibility aliases, defsubsts, and macros...

Compatibility aliases, defsubsts, and macros...

[Bill Wohler]

I'm a bit confused by the compatibility alias conventions and was hoping
someone could clarify them for me.

In (elisp)Coding Conventions, I read:

  1. It is a bad idea to define aliases for the Emacs primitives.
     Normally you should use the standard names instead.  The case
     where an alias may be useful is where it facilitates backwards
     compatibility or portability.

  2. If a package needs to define an alias or a new function for
     compatibility with some other version of Emacs, name it with the
     package prefix, not with the raw name with which it occurs in the
     other version.  Here is an example from Gnus, which provides many
     examples of such compatibility issues.

          (defalias 'gnus-point-at-bol
            (if (fboundp 'point-at-bol)
                'point-at-bol
              'line-beginning-position))

Unless I'm missing a subtlety, these two paragraphs seem incompatible
with each other. The following seems OK by #1 but not by #2:

    (unless (fboundp 'assoc-string)
      (defsubst assoc-string (key list case-fold)
	"Like `assoc' but specifically for strings.
    Case is ignored if CASE-FOLD is non-nil.
    This function added by MH-E for Emacs versions that lack
    `assoc-string', introduced in Emacs 22."
	(if case-fold
	    (assoc-ignore-case key list)
	  (assoc key list))))

This seems preferable to creating a function, macro, or alias
mh-assoc-string which provides no value-add. In the future, when Emacs
22 is the oldest Emacs version supported, we can simply remove the
defsubst and not have to modify the code that calls it. Readers of the
code will be able to quickly read "assoc-string" but will be slowed by
having to check the docstring or code for "mh-assoc-string" to check for
special treatment of our function.

Or perhaps this is OK. Since it does nothing in Emacs 22, it is OK by
point #1. Since it is using the Emacs name rather than the name in an
"other version" of Emacs, it is OK by #2.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Compatibility aliases, defsubsts, and macros...

[Miles Bader]

2006/1/31, Bill Wohler <wohler@newt.com>:
> Unless I'm missing a subtlety, these two paragraphs seem incompatible
> with each other. The following seems OK by #1 but not by #2:

#1 just means "don't _gratuitously_ add aliases simply for the purpose
of making your code look neat" (which for whatever reason lots of
people seem to like to do).

E.g., don't add (defalias 'miles-car 'car) and call "miles-car"
everywhere -- you know car is going to be defined.

#2 then says "In the case where you _need_, for portability, to define
your own version of a standard emacs function on certain platforms, do
_not_ use the standard emacs name for it, instead use a
package-specific name, and add an alias in the case where the Emacs
standard definition is ok."

#2 is very important; the bad old practice of just defining the
standard functions on systems which didn't have it built in (as you
demonstrate) caused many problems.

-miles
--
Do not taunt Happy Fun Ball.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Compatibility aliases, defsubsts, and macros...

[Bill Wohler]

Thanks, Miles.

Miles Bader <miles@gnu.org> wrote:

> 2006/1/31, Bill Wohler <wohler@newt.com>:
> > Unless I'm missing a subtlety, these two paragraphs seem incompatible
> > with each other. The following seems OK by #1 but not by #2:
> 
> #1 just means "don't _gratuitously_ add aliases simply for the purpose
> of making your code look neat" (which for whatever reason lots of
> people seem to like to do).

That's what I figured. But then why cloud the issue by adding the second
sentence which seems in conflict with #2?

> #2 is very important; the bad old practice of just defining the
> standard functions on systems which didn't have it built in (as you
> demonstrate) caused many problems.

Glad I asked. Will rename the defsubst.

Just out of curiosity, do you remember the problems?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Compatibility aliases, defsubsts, and macros...

[Miles Bader]

2006/1/31, Bill Wohler <wohler@newt.com>:
> > #2 is very important; the bad old practice of just defining the
> > standard functions on systems which didn't have it built in (as you
> > demonstrate) caused many problems.
>
> Just out of curiosity, do you remember the problems?

It intereferes with other packages that are trying to test the
environment by probing the existance or non-existance of certain
functions.  So while it may work fine with just _one_ such package
installed, as soon as you try to load the next one, things blow up. 
Well, usually not "blow up", but instead subtle and hard-to-diagnose
misbehavior.

[If all packages (1) _only_ used function testing on a
function-by-function basis, and (2) defined subsitute definitions
which were perfectly functional, and (3) did not use function testing
for any purpose other than defining a single replacement function,
_then_ it might all work -- but these conditions are most definitely
not satisfied by many packages out there, and even a single package
can cause grief for all the others loaded with it.]

w3 is probably the most famous case of code that used this practice
and caused problems as a result.

-miles
--
Do not taunt Happy Fun Ball.

Re: Compatibility aliases, defsubsts, and macros...

[Bill Wohler]

Miles Bader <miles@gnu.org> wrote:

> 2006/1/31, Bill Wohler <wohler@newt.com>:
> > > #2 is very important; the bad old practice of just defining the
> > > standard functions on systems which didn't have it built in (as you
> > > demonstrate) caused many problems.
> >
> > Just out of curiosity, do you remember the problems?
> 
> It intereferes with other packages that are trying to test the
> environment by probing the existance or non-existance of certain
> functions.

"Bing." Lightbulb goes off. Got it. Of course. Thanks.

Fixing those baddies in MH-E now before you notice ;-).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Compatibility aliases, defsubsts, and macros...

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> Miles Bader <miles@gnu.org> wrote:
>
>> 2006/1/31, Bill Wohler <wohler@newt.com>:
>> > > #2 is very important; the bad old practice of just defining the
>> > > standard functions on systems which didn't have it built in (as you
>> > > demonstrate) caused many problems.
>> >
>> > Just out of curiosity, do you remember the problems?
>> 
>> It intereferes with other packages that are trying to test the
>> environment by probing the existance or non-existance of certain
>> functions.
>
> "Bing." Lightbulb goes off. Got it. Of course. Thanks.
>
> Fixing those baddies in MH-E now before you notice ;-).

Done.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642