[Rd] (no) circular dependency

[Dmitri Popavenko]

Thanks all, I don't know either (for the moment).
It's all in the design phase still. Generally, I would also like to keep
specific functions in specific packages, if at all possible.

On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com>
wrote:

> 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]]