Suppose you have made changes to a package for local use, but you need
to be able to deploy it within your organization. This isn't the kind
of change you would submit to the author, just a local tweak.
If it's something small, does it make more sense to keep a local cvs
tree for the external package, or simply to include the modified
functions in the current package so they will be re-defined when
loaded?
Jonathon McKitrick wrote:
> Suppose you have made changes to a package for local use, but you need
> to be able to deploy it within your organization. This isn't the kind
> of change you would submit to the author, just a local tweak.
>
> If it's something small, does it make more sense to keep a local cvs
> tree for the external package, or simply to include the modified
> functions in the current package so they will be re-defined when
> loaded?
Use conduits.
Tim Bradshaw wrote:
> Jonathon McKitrick wrote:
> > Suppose you have made changes to a package for local use, but you need
> > to be able to deploy it within your organization. This isn't the kind
> > of change you would submit to the author, just a local tweak.
> >
> > If it's something small, does it make more sense to keep a local cvs
> > tree for the external package, or simply to include the modified
> > functions in the current package so they will be re-defined when
> > loaded?
>
> Use conduits.
Sorry, to elaborate. If you want to modify things associated with
foo:bar and foo:fish:
(defpackage :com.mycompany.foo
;; this is org.tfeb.conduit-packages:defpackage
(:use :cl)
(:extends/excluding :foo #:bar #:fish)
(:export #:bar #:fish))
...
(in-package :com.mycompany.foo)
(defun bar (...)
... foo:bar ...)
(defmacro fish ...
...)
Then you only need to maintain the patch.
Tim Bradshaw wrote:
> Sorry, to elaborate. If you want to modify things associated with
> foo:bar and foo:fish:
>
> (defpackage :com.mycompany.foo
> ;; this is org.tfeb.conduit-packages:defpackage
> (:use :cl)
> (:extends/excluding :foo #:bar #:fish)
> (:export #:bar #:fish))
>
> ...
> (in-package :com.mycompany.foo)
>
> (defun bar (...)
> ... foo:bar ...)
Now the magic question: how does this work with CLOS?
If I only want to override a method specialized on one class, can I do
that?
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> Tim Bradshaw wrote:
>> Sorry, to elaborate. If you want to modify things associated with
>> foo:bar and foo:fish:
>>
>> (defpackage :com.mycompany.foo
>> ;; this is org.tfeb.conduit-packages:defpackage
>> (:use :cl)
>> (:extends/excluding :foo #:bar #:fish)
>> (:export #:bar #:fish))
>>
>> ...
>> (in-package :com.mycompany.foo)
>>
>> (defun bar (...)
>> ... foo:bar ...)
>
> Now the magic question: how does this work with CLOS?
>
> If I only want to override a method specialized on one class, can I do
> that?
Classes are totally orthogonal to packages in Common Lisp.
(defgeneric truc (self))
(defmethod truc ((self Chose)) ...)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Pascal Bourguignon wrote:
> Classes are totally orthogonal to packages in Common Lisp.
Here's an example of what I need to do. The package cl-pdf has
(draw-object) specialized on each of several parts of a chart: the
x-axis, the y-axis, the legend, and the data itself. I need to
maintain my own version of the legend-drawing code, without interfering
with or needing to duplicate the other (draw-object) methods.
Since defpackage only deals with function/method names, not signatures,
how do I do this?
I want to override draw-object ((obj legend)) but not draw-object ((obj
axis)) or ((obj plot)), and defpackage only lets me write
#:draw-object.
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <uhd6vblho.fsf@agharta.de>
On 19 Feb 2006 03:58:01 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> Here's an example of what I need to do. The package cl-pdf has
> (draw-object) specialized on each of several parts of a chart: the
> x-axis, the y-axis, the legend, and the data itself. I need to
> maintain my own version of the legend-drawing code, without
> interfering with or needing to duplicate the other (draw-object)
> methods.
>
> Since defpackage only deals with function/method names, not
> signatures, how do I do this?
>
> I want to override draw-object ((obj legend)) but not draw-object
> ((obj axis)) or ((obj plot)), and defpackage only lets me write
> #:draw-object.
As has already been said, packages are a completely orthogonal
concept. You should understand that first before you're trying to
continue with this.
As far as your problem is concerned, you could subclass LEGEND and
write your own DRAW-OBJECT method for it. That's basic OOP.
Or you can use BEFORE, AFTER, or AROUND methods.
Cheers,
Edi.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> As has already been said, packages are a completely orthogonal
> concept. You should understand that first before you're trying to
> continue with this.
Perhaps this is the more relevant question:
If I use conduit-packages and exclude #:foo, will that exclude ALL
symbols 'foo' or just those that I redefine?
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <ud5hjbia9.fsf@agharta.de>
On 19 Feb 2006 05:00:08 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> If I use conduit-packages and exclude #:foo, will that exclude ALL
> symbols 'foo' or just those that I redefine?
I haven't used Conduits yet but I think you're talking about the
:EXTENDS/EXCLUDING option. To me it looks like with it you can
exclude specific symbols from a package (and import everything else).
So, it doesn't make sense to talk about "ALL symbols 'foo'" - there's
always at most /one/ symbol with the name 'foo' per package. And you
don't "redefine" symbols either - they're either there or not.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 19 Feb 2006 05:00:08 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
>
> > If I use conduit-packages and exclude #:foo, will that exclude ALL
> > symbols 'foo' or just those that I redefine?
>
> I haven't used Conduits yet but I think you're talking about the
> :EXTENDS/EXCLUDING option. To me it looks like with it you can
> exclude specific symbols from a package (and import everything else).
> So, it doesn't make sense to talk about "ALL symbols 'foo'" - there's
> always at most /one/ symbol with the name 'foo' per package. And you
> don't "redefine" symbols either - they're either there or not.
Yes, I'd use :extends/excluding.
To clarify: I meant all methods 'foo'. I want to override foo
specialized on legend, not foo specialized on anything else.
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <uvevba1n7.fsf@agharta.de>
On 19 Feb 2006 05:53:51 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> Yes, I'd use :extends/excluding.
>
> To clarify: I meant all methods 'foo'. I want to override foo
> specialized on legend, not foo specialized on anything else.
So, conduits won't help you. You can exclude one /symbol/, you can't
exclude specific methods or whatever. Packages contain symbols, and
symbols just happen to name (amongst other things) functions. And
they always name the whole generic function, not only constituent
methods.
(Was that better, Kenny?)
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Alexander Schmolck
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <yfs1wxzqtp2.fsf@oc.ex.ac.uk>
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> Edi Weitz wrote:
> > As has already been said, packages are a completely orthogonal
> > concept. You should understand that first before you're trying to
> > continue with this.
>
> Perhaps this is the more relevant question:
>
> If I use conduit-packages and exclude #:foo, will that exclude ALL
> symbols 'foo' or just those that I redefine?
I think you're apparent misunderstanding results from the fact that you think
CL to have a module system wheras in fact it has a package system (it deals
with names and not with values). There is only at most one symbol foo in any
one package.
If you export it, you give the importer access to the top-level variable foo,
the function/method(s) foo, the type foo and so on and so on -- possibly even
to things for which you defined your namespace.
If you are desperate for a module system, you'll need a scheme dialect.
'as
Edi Weitz wrote:
> On 19 Feb 2006 03:58:01 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
>
>
>>Here's an example of what I need to do. The package cl-pdf has
>>(draw-object) specialized on each of several parts of a chart: the
>>x-axis, the y-axis, the legend, and the data itself. I need to
>>maintain my own version of the legend-drawing code, without
>>interfering with or needing to duplicate the other (draw-object)
>>methods.
>>
>>Since defpackage only deals with function/method names, not
>>signatures, how do I do this?
>>
>>I want to override draw-object ((obj legend)) but not draw-object
>>((obj axis)) or ((obj plot)), and defpackage only lets me write
>>#:draw-object.
>
>
> As has already been said, packages are a completely orthogonal
> concept. You should understand that first before you're trying to
> continue with this.
Yes, so why does not someone explain it?
> Classes are totally orthogonal to packages in Common Lisp.
>
> (defgeneric truc (self))
> (defmethod truc ((self Chose)) ...)
The above is the entirety of "as has already been said". <sigh>
>
> As far as your problem is concerned, you could subclass LEGEND and
> write your own DRAW-OBJECT method for it. That's basic OOP.
>
> Or you can use BEFORE, AFTER, or AROUND methods.
Well, at least you gave him the fish. :)
To the OP, your problem is not that cl-pdf:draw in general does not do
what you want in the sense of "gee, I wanted to use 'draw-object' for
taking objects out of a pocket". Your problem is that you want to change
what gets done by draw-object on legends.
In the world of OO, that really means you do not want to use legends. As
is. This is because OO talks about the behavior of an object being part
of the essence of an object, ideally the only published essence, with
structure being mere implementation. And the behavior of an object is
just an abstraction over the methods specialized on it.
That explains Pascal's "orthogonal" swipe at you.
Of course, you are OK with most of legend's behavior, so you do not want
to reinvent the whole wheel. That explains Edi's suggestion to subclass
legend, so you can supply a different draw-object method (tho it often
happens that soon enough you find another reason to have your own legend
subclass).
Then the only question is, will the cl-pdf chart class allow you to
specify the class used for legends? If not, (a) thank god for open
source and (b) you have more work to do. You probably do not want to
fork cl-pdf, so just duplicate all the chart code, call it superchart,
and start parameterizing. If that sounds like hell...
> Or you can use BEFORE, AFTER, or AROUND methods.
I doubt you can get the result you want with mere before or after
augmentation, but the :around option is kind of a big hammer that lets
you kind of replace the default behavior. I say "kind of" because you
will not call call-next-method in your :around method, and so might miss
out on necessary implementation handled by cl-pdf methods normally
invoked. Not good.
kenny
Kenny Tilton wrote:
> Then the only question is, will the cl-pdf chart class allow you to
> specify the class used for legends? If not, (a) thank god for open
> source and (b) you have more work to do. You probably do not want to
> fork cl-pdf, so just duplicate all the chart code, call it superchart,
> and start parameterizing. If that sounds like hell...
That's exactly right. The legend object is internal to the chart
object, and is created during make-instance of the chart. It is NOT an
external object that is passed in. If it WERE, this would all be much
simpler.
> > Or you can use BEFORE, AFTER, or AROUND methods.
>
> I doubt you can get the result you want with mere before or after
> augmentation, but the :around option is kind of a big hammer that lets
> you kind of replace the default behavior. I say "kind of" because you
> will not call call-next-method in your :around method, and so might miss
> out on necessary implementation handled by cl-pdf methods normally
> invoked. Not good.
Or, I can just go into cl-pdf where (draw-object legend) is called, and
comment it out.
<swinging sledge-hammer>
Also not good, but like I always say, It Works For Me (TM).
If there's a better way that is fast, I'll try it. If not, I'll just
revisit this issue later.
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <u4q2vbgiz.fsf@agharta.de>
On 19 Feb 2006 05:52:16 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> Or, I can just go into cl-pdf where (draw-object legend) is called,
> and comment it out.
> <swinging sledge-hammer>
You don't have to, just redefine it - see my other posting.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jonathon McKitrick wrote:
> Kenny Tilton wrote:
>
>>Then the only question is, will the cl-pdf chart class allow you to
>>specify the class used for legends? If not, (a) thank god for open
>>source and (b) you have more work to do. You probably do not want to
>>fork cl-pdf, so just duplicate all the chart code, call it superchart,
>>and start parameterizing. If that sounds like hell...
>
>
> That's exactly right. The legend object is internal to the chart
> object, and is created during make-instance of the chart. It is NOT an
> external object that is passed in. If it WERE, this would all be much
> simpler.
>
>
>> > Or you can use BEFORE, AFTER, or AROUND methods.
>>
>>I doubt you can get the result you want with mere before or after
>>augmentation, but the :around option is kind of a big hammer that lets
>>you kind of replace the default behavior. I say "kind of" because you
>>will not call call-next-method in your :around method, and so might miss
>>out on necessary implementation handled by cl-pdf methods normally
>>invoked. Not good.
>
>
> Or, I can just go into cl-pdf where (draw-object legend) is called, and
> comment it out.
> <swinging sledge-hammer>
>
> Also not good, but like I always say, It Works For Me (TM).
Well, the chart code is just example code, right? So no harm in hacking
on it, except now when you grab a new copy of cl-pdf you lose your hacks
and have to re-hack.
Maybe the problem is using example code as if it were a serious library
offering. If it were the latter, it would be more customizable.
Yes, that's the Real Problem. Not defpackage, not OO, not cl-chart being
insufficiently customizable. You are using a toss-off example as
production code. Stop that. :)
Instead, rip the whole thing out and make it part of your code and do
what you want with it. new releases of cl-pdf then get absorbed without
a problem.
kenny
Kenny Tilton wrote:
> Well, the chart code is just example code, right? So no harm in hacking
No. That would be examples/example.lisp. ;-)
I have an idea. I'll use CLOS and redefine the method or derive a new
class. Oh, wait, that sounds vaguely familiar... :-)
Kenny Tilton wrote:
> Jonathon McKitrick wrote:
>
>> Kenny Tilton wrote:
>>
>>> Then the only question is, will the cl-pdf chart class allow you to
>>> specify the class used for legends? If not, (a) thank god for open
>>> source and (b) you have more work to do. You probably do not want to
>>> fork cl-pdf, so just duplicate all the chart code, call it superchart,
>>> and start parameterizing. If that sounds like hell...
>>
>>
>>
>> That's exactly right. The legend object is internal to the chart
>> object, and is created during make-instance of the chart. It is NOT an
>> external object that is passed in. If it WERE, this would all be much
>> simpler.
>>
>>
>>> > Or you can use BEFORE, AFTER, or AROUND methods.
>>>
>>> I doubt you can get the result you want with mere before or after
>>> augmentation, but the :around option is kind of a big hammer that lets
>>> you kind of replace the default behavior. I say "kind of" because you
>>> will not call call-next-method in your :around method, and so might miss
>>> out on necessary implementation handled by cl-pdf methods normally
>>> invoked. Not good.
>>
>>
>>
>> Or, I can just go into cl-pdf where (draw-object legend) is called, and
>> comment it out.
>> <swinging sledge-hammer>
>>
>> Also not good, but like I always say, It Works For Me (TM).
>
>
> Well, the chart code is just example code, right? So no harm in hacking
> on it, except now when you grab a new copy of cl-pdf you lose your hacks
> and have to re-hack.
>
> Maybe the problem is using example code as if it were a serious library
> offering. If it were the latter, it would be more customizable.
>
> Yes, that's the Real Problem. Not defpackage, not OO, not cl-chart being
> insufficiently customizable. You are using a toss-off example as
> production code. Stop that. :)
A middle ground that just occurred to me is to modify cl-chart such that
it takes parameters for the classes to be used for axis, legend,
whatever and offer the enhancements back to the maintainer.
kt
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> Kenny Tilton wrote:
>> Then the only question is, will the cl-pdf chart class allow you to
>> specify the class used for legends? If not, (a) thank god for open
>> source and (b) you have more work to do. You probably do not want to
>> fork cl-pdf, so just duplicate all the chart code, call it superchart,
>> and start parameterizing. If that sounds like hell...
>
> That's exactly right. The legend object is internal to the chart
> object, and is created during make-instance of the chart. It is NOT an
> external object that is passed in. If it WERE, this would all be much
> simpler.
Perhaps it would be simple enough to patch the method
initialize-instance of cl-pdf to accept a legend-class argument and
use it instead of 'legend in the make-instance calls cl-pdf does.
Then you can just pass your subclass of legend to cl-pdf.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <uzmkna1so.fsf@agharta.de>
On Sun, 19 Feb 2006 13:24:20 GMT, Kenny Tilton <·············@nyc.rr.com> wrote:
> Yes, so why does not someone explain it?
Dunno, because there are enough online resources already? You don't
explain it either... :)
<http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html>
>> Classes are totally orthogonal to packages in Common Lisp.
>> (defgeneric truc (self))
>> (defmethod truc ((self Chose)) ...)
>
> The above is the entirety of "as has already been said". <sigh>
Although your citation style made it look as if I had written the
stuff above, I haven't.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <u8xs7bhyn.fsf@agharta.de>
On 19 Feb 2006 03:58:01 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> I want to override draw-object ((obj legend)) but not draw-object
> ((obj axis)) or ((obj plot)), and defpackage only lets me write
> #:draw-object.
Why don't you just load CL-PDF and redefine this specific method
afterwards? Depending on your Lisp implementation you might get a
warning about rededifinition of the same method in a another source
file but other than that you should be fine.
···@miles:/tmp$ cat foo.lisp
(defclass a () ())
(defmethod bar ((a a))
(format t "BAR from file foo.lisp called.~%"))
(defmethod foo ((a a))
(bar a))
···@miles:/tmp$ cat bar.lisp
(defmethod bar ((a a))
(format t "BAR from file bar.lisp called.~%"))
···@miles:/tmp$ lw
LispWorks(R): The Common Lisp Programming Environment
Copyright (C) 1987-2005 LispWorks Ltd. All rights reserved.
Version 4.4.6
Saved by root as lispworks-console-4460, at 03 Nov 2005 0:21
User edi on miles
; Loading text file /usr/local/lib/LispWorks/lib/4-4-0-0/config/siteinit.lisp
; Loading text file /usr/local/lib/LispWorks/lib/4-4-0-0/private-patches/load.lisp
; Loading text file /home/edi/.lispworks
; Loading text file /usr/local/lisp/source/lboot/start.lisp
; Loading fasl file /usr/local/lisp/source/lboot/lib/.bin/lispworks4.4/asdf.ufsl
; Loading fasl file /usr/local/lisp/source/lboot/lib/.bin/lispworks4.4/defsystem.ufsl
; Loading fasl file /usr/local/lisp/source/lboot/.bin/lispworks4.4/utils.ufsl
; Loading fasl file /usr/local/lisp/source/lboot/.bin/lispworks4.4/systems.ufsl
; Loading fasl file /usr/local/lisp/source/lboot/.bin/lispworks4.4/non-clc.ufsl
CL-USER 1 > (load (compile-file "foo.lisp"))
;;; Compiling file foo.lisp ...
;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0
;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3
;;; Source level debugging is on
;;; Source file recording is on
;;; Cross referencing is on
; (TOP-LEVEL-FORM 1)
; (DEFCLASS A)
; (METHOD BAR (A))
; (METHOD FOO (A))
; (TOP-LEVEL-FORM 2)
; Loading fasl file /tmp/foo.ufsl
#P"/tmp/foo.ufsl"
CL-USER 2 > (foo (make-instance 'a))
BAR from file foo.lisp called.
NIL
CL-USER 3 > (load (compile-file "bar.lisp"))
;;; Compiling file bar.lisp ...
;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0
;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3
;;; Source level debugging is on
;;; Source file recording is on
;;; Cross referencing is on
; (TOP-LEVEL-FORM 1)
; (METHOD BAR (A))
; (TOP-LEVEL-FORM 2)
; Loading fasl file /tmp/bar.ufsl
Warning: (METHOD BAR (A)) being redefined in /tmp/bar.lisp (previously in /tmp/foo.lisp).
#P"/tmp/bar.ufsl"
CL-USER 4 > (foo (make-instance 'a))
BAR from file bar.lisp called.
NIL
Cheers,
Edi.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Thomas A. Russ
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <ymiwtfod23x.fsf@sevak.isi.edu>
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> Pascal Bourguignon wrote:
> > Classes are totally orthogonal to packages in Common Lisp.
>
> Here's an example of what I need to do. The package cl-pdf has
> (draw-object) specialized on each of several parts of a chart: the
> x-axis, the y-axis, the legend, and the data itself. I need to
> maintain my own version of the legend-drawing code, without interfering
> with or needing to duplicate the other (draw-object) methods.
>
> Since defpackage only deals with function/method names, not signatures,
> how do I do this?
>
> I want to override draw-object ((obj legend)) but not draw-object ((obj
> axis)) or ((obj plot)), and defpackage only lets me write
> #:draw-object.
There are two approaches.
1. If you want this to be a globally visible change, in the sense that
all code running in the image see and use the new DRAW-OBJECT for
legends code, then you should consider using an :AROUND method on
DRAW-OBJECT for legends. (Or possibly :BEFORE or :AFTER).
2. If you want it to be more local, then if you use the standard
package operations, you will end up shadowing the symbol DRAW-OBJECT.
In that case, you just write your own methods like
(defmethod draw-objeect ((obj t))
;; Pass through drawing to CL-PDF as the default
(cl-pdf:draw-object obj))
(defmethod draw-objeect ((obj legend))
;; My special code
...do whatever needs to be done...
)
--
Thomas A. Russ, USC/Information Sciences Institute
Jonathon McKitrick wrote:
> Now the magic question: how does this work with CLOS?
>
> If I only want to override a method specialized on one class, can I do
> that?
No, not really, because packages and classes don't have anything to do
with each other in CL. A better approach is to use CLOS to do this
itself - define an around method, or (perhaps better) use (heh) my
wrapping-standard method combination to define `wrapper' methods which
happen completely outside the normal method combination.
--tim
(Damn, several news posts within a month, I am slipping here...)
From: Edi Weitz
Subject: Re: Managing/incorporating modifications to external packages
Date:
Message-ID: <uu0b0k2si.fsf@agharta.de>
On 15 Feb 2006 08:04:11 -0800, "Tim Bradshaw" <··········@tfeb.org> wrote:
> Use conduits.
<http://www.tfeb.org/lisp/hax.html>
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jonathon McKitrick wrote:
> If it's something small, does it make more sense to keep a local cvs
> tree for the external package, or simply to include the modified
> functions in the current package so they will be re-defined when
> loaded?
If you have the source of the package, commit the whole package to CVS as a
vendor branch (also available in SVN). Then you can rewrite whatever you
want, but it will be still possible to use later releases from the original
author. It's always a good idea to have all source code in CVS, even if you
don't change the external package.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de