From sethfalcon at gmail.com  Fri Sep  9 23:08:53 2005
From: sethfalcon at gmail.com (Seth Falcon)
Date: Fri, 09 Sep 2005 14:08:53 -0700
Subject: [Rd] two almost identical packages: best practice
References: <8B2D83C0-69CF-48DA-BF80-98ECC67AF55B@soc.soton.ac.uk>
Message-ID: <m24q8udk4a.fsf@macaroni.local>

On  9 Sep 2005, r.hankin at noc.soton.ac.uk wrote:
> I have written a whole bunch of methods for objects of class
> "octonion".
>
> So far I've done about a dozen generic functions such as
> seq.octonion(), rep.octonion(), [<-.octonion(), and so on and so on.
>
> Very nearly all  of these functions are applicable to objects of  
> class "quaternion".

One solution would be to define a common base class (perhaps nionBase? ;-)
and put the common methods there.

So in S3 I guess you'd have an Im.nionBase function and your octonions
and quaternions would be subclasses of nionBase.

> (x))" but would be otherwise identical.  A similar story holds for
> each of maybe twenty generic functions.  Nearly all the Rd files are
> similarly identical: the word "octonion" replaces the word
> "octonion".  I suppose "A" changes to "An" as well.

If you document the generics for the base class, I think that would
work.  Otherwise, find/replace.

> There is a small number of functions and datasets that are specific
> to octonions.
>
> What is Best Practice in this situation?  I don't want to edit two  
> separate
> packages in tandem.   Is there a mechanism for doing what I want
> in the context of a bundle?

If they need to be in separate packages, perhaps you have three
packages:

nionBase
quaternion (depends on nionBase)
etc.

HTH,

+ seth



[Rd] two almost identical packages: best practice
Seth Falcon