From henrik.bengtsson at gmail.com  Mon Oct 26 02:32:11 2015
From: henrik.bengtsson at gmail.com (Henrik Bengtsson)
Date: Sun, 25 Oct 2015 18:32:11 -0700
Subject: [Rd] Best way to implement optional functions?
In-Reply-To: <562967B1.1010801@gmail.com>
References: <56293F15.80509@gmail.com> <562967B1.1010801@gmail.com>
Message-ID: <CAFDcVCQjVu2k9nhPEJGiDEy4A=rgkHvepcW-YbGivbL6rYrZjg@mail.gmail.com>

On Thu, Oct 22, 2015 at 3:48 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:
>
>
> On 10/22/2015 03:55 PM, Duncan Murdoch wrote:
>>
>> I'm planning on adding some new WebGL functionality to the rgl package,
>> but it will pull in a very large number of dependencies. Since many
>> people won't need it, I'd like to make the new parts optional.
>>
>> The general idea I'm thinking of is to put the new stuff into a separate
>> package, and have rgl "Suggest" it.  But I'm not sure whether these
>> functions  should only be available in the new package (so users would
>> have to attach it to use them), or whether they should be in rgl, but
>> fail if the new package is not available for loading.
>>
>> Can people suggest other packages that solve this kind of problem in a
>> good way?
>
>
> I do something similar in several packages. I would distinguish between the
> situation where the new functions have some functionality without all the
> extra dependencies, and the case where they really do not. In the former
> case it makes sense to put the functions in rgl and then fail when the extra
> functionality is demanded and not available. In the latter case, it "feels
> like" you are trying to defeat Depends: or Imports:. That route has usually
> gotten me in trouble.
>
> Another thing you might want to consider is that, at least for awhile, the
> new functions in rglPlus will probably be less stable then those in rgl.
> Being able to change those and update rglPlus without needing to update rgl
> can be a real advantage (i.e. if the API for the new functions is in rgl,
> and you need to change it, then you are required to notify all the package
> maintainers that depend on rgl, do reverse testing, and you have to explain
> that your update of rgl is going to break rglPlus and you have a new version
> of that but you cannot submit that yet because it will not work until the
> new rgl is in place.)

I favor the latter solution; keep rgl as a core package and add bells
and whistles to rglPlus and have rglPlus attach rgl so that people
using the extra functions can just do library(rglPlus).  This way rgl
does not have to "know about" rglPlus.  Not sure if this design is
possible, or rgl do need to have to know about rglPlus.

/Henrik

>
> Paul
>
>>
>> Duncan Murdoch
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Best way to implement optional functions?
Henrik Bengtsson