Re: Things I would like to be added after the release

[T. V. Raman]

well said.

I still dont quite understand why:

A)      maintaining a package inside Emacs is somehow different
        than maintaining it "outside"

B)      The only advantage to having a package "inside" the emacs
        distrib is user convenience -- should that be offset by
        forcing things like ECB to be rewritten? Feels like that
        time could be more usefully spent writing more Free
        software, rather than writing the same free software
        differently



>>>>> "Stephen" == Stephen J Turnbull <address@hidden> writes:
    Stephen> Nick Roberts writes:
    >> T. V. Raman writes
    Stephen> 
    >>> I'm also speaking from my own experience of maintaining a
    >>> rather large package that is mostly built on advice. And
    >>> using pre/post command hooks to implement it I believe
    >>> would have made the codebase impossible to maintain.
    Stephen> 
    >> I think you're talking of maintaining a package outside of
    >> Emacs while others are talking about doing it _within_
    >> Emacs.
    Stephen> 
    Stephen> No, he's talking about using advice rather than
    Stephen> hooks.  As we've seen recently with menu items,
    Stephen> callbacks are prone to being implemented as lambdas
    Stephen> which are undocumented except by their source, hard
    Stephen> to debug, and you don't know they are there unless
    Stephen> you look specifically at the hook variable (not the
    Stephen> function doc! ... it would be a good idea to fix
    Stephen> that).  By contrast, advice automatically documents
    Stephen> that the function is advised, and automatically
    Stephen> displays the docstring that tells you what changes
    Stephen> have been made to behavior.
    Stephen> 
    Stephen> More fundamentally, advice (as a class of derived
    Stephen> function) follows a stack discipline, and can be
    Stephen> read from the outside in, stopping when you reach a
    Stephen> function you fully understand.  By contrast, hooks
    Stephen> (again, as a class) are totally undisciplined; you
    Stephen> must read the source of *all* functions on the hook,
    Stephen> you must worry about interactions due to varying
    Stephen> order in different instances, and you must read the
    Stephen> source of the function using the hook to understand
    Stephen> it in full.
    Stephen> 
    Stephen> Of course I'm telling only a partial story here,
    Stephen> emphasizing the advantages of advice over hooks.
    Stephen> But it does have advantages, and AFAICS the jury is
    Stephen> still out on whether those can outweigh the
    Stephen> disadvantages.

-- 
Best Regards,
--raman

      
Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: address@hidden
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs