[Rd] (no) circular dependency

[Mark van der Loo]

Well, I'm not saying that Dmitri _should_ do it. I merely mention it as an
option that I think is worth thinking about -- it is easy to overlook the
obvious :-). Since we have no further info on the package's structure we
can't be sure..




Op vr 8 apr. 2016 om 13:59 schreef Adrian Dușa <dusa.adrian at unibuc.ro>:

> Hi Mark,
>
> Uhm... sometimes this is not always possible.
> For example I have a package QCA which produces truth tables (all
> combinations of presence / absence of causal conditions), and it uses the
> venn package to draw a Venn diagram.
> It is debatable if one should assimilate the "venn" package into the QCA
> package (other people might want Venn diagrams but not necessarily the
> other QCA functions).
>
> On the other hand, the package venn would like to use the QCA package to
> demonstrate its abilities to plot Venn diagrams based on truth tables
> produced by the QCA package. Both have very different purposes, yet both
> use functions from each other.
>
> So I'm with Bill Dunlap here that several smaller packages are preferable
> to one larger one, but on the other hand I can't separate those functions
> into a third package: the truth table production is very specific to the
> QCA package, while plotting Venn diagrams is very specific to the venn
> package. I don't see how to separate those functions from their main
> packages and create a third one that each would depend on.
>
> This is just an example, there could be others as well, reason for which I
> am (still) looking for a solution to:
> - preserve the current functionalities in packages A and B (to follow
> Dmitri's original post)
> - be able to use functions from each other
> - yet avoid circular dependency
>
> I hope this explains it,
> Adrian
>
>
> On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
> mark.vanderloo at gmail.com> wrote:
>
>> At the risk of stating the over-obvious: there's also the option of
>> creating just a single package containing all functions. None of the
>> functions that create the interdependencies need to be exported that way.
>>
>> Btw, his question is probably better at home at the r-package-devel list.
>>
>>
>> Best,
>>
>> M
>>
>>
>>
>>
>> On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko <dmitri.popavenko at gmail.com>
>> wrote:
>>
>>> Hi Thierry,
>>>
>>> Thanks for that, the trouble is functions are package specific so moving
>>> from one package to another could be a solution, but I would rather save
>>> that as a last resort.
>>>
>>> As mentioned, creating a package C with all the common functions could
>>> also
>>> be an option, but this strategy quickly inflates the number of packages
>>> on
>>> CRAN. If no other option is possible, that could be the way but I was
>>> still
>>> thinking about a more direct solution if possible.
>>>
>>> Best,
>>> Dmitri
>>>
>>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>>> thierry.onkelinx at inbo.be>
>>> wrote:
>>>
>>> > Dear Dmitri,
>>> >
>>> > If it's only a small number of functions then move them the relevant
>>> > functions for A to B so that B works without A. Then Import these
>>> functions
>>> > from B in A. Hence A depends on B but B is independent of A.
>>> >
>>> > It is requires to move a lot of functions than you better create a
>>> package
>>> > C with all the common functions. Then A and B import those functions
>>> from C.
>>> >
>>> > Best regards,
>>> >
>>> > ir. Thierry Onkelinx
>>> > Instituut voor natuur- en bosonderzoek / Research Institute for Nature
>>> and
>>> > Forest
>>> > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
>>> > Kliniekstraat 25
>>> > 1070 Anderlecht
>>> > Belgium
>>> >
>>> > To call in the statistician after the experiment is done may be no more
>>> > than asking him to perform a post-mortem examination: he may be able
>>> to say
>>> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
>>> > The plural of anecdote is not data. ~ Roger Brinner
>>> > The combination of some data and an aching desire for an answer does
>>> not
>>> > ensure that a reasonable answer can be extracted from a given body of
>>> data.
>>> > ~ John Tukey
>>> >
>>> > 2016-04-06 8:42 GMT+02:00 Dmitri Popavenko <dmitri.popavenko at gmail.com
>>> >:
>>> >
>>> >> Hello all,
>>> >>
>>> >> I would like to build two packages (say A and B), for two different
>>> >> purposes.
>>> >> Each of them need one or two functions from the other, which leads to
>>> the
>>> >> problem of circular dependency.
>>> >>
>>> >> Is there a way for package A to import a function from package B, and
>>> >> package B to import a function from package A, without arriving to
>>> >> circular
>>> >> dependency?
>>> >> Other suggestions in the archive mention building a third package that
>>> >> both
>>> >> A and B should depend on, but this seems less attractive.
>>> >>
>>> >> I read about importFrom() into the NAMESPACE file, but I don't know
>>> how to
>>> >> relate this with the information in the DESCRIPTION file (other than
>>> >> adding
>>> >> each package to the Depends: field).
>>> >>
>>> >> Thank you,
>>> >> Dmitri
>>> >>
>>> >>         [[alternative HTML version deleted]]
>>> >>
>>> >> ______________________________________________
>>> >> R-devel at r-project.org mailing list
>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >>
>>> >
>>> >
>>>
>>>         [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr.90
> 050663 Bucharest sector 5
> Romania
>

	[[alternative HTML version deleted]]