Yep. And w.r.t. empty objects, make sure new("MyClass") works and
returns a valid object. This should produce an "empty" object.
Note that the explicit constructor function should be named as the
class itself (e.g. MyClass()). It's up to you to decide whether
it should support being called with no arguments (and behave just
like new("MyClass") in that case).
Cheers,
H.
On 09/28/2017 10:13 AM, Michael Lawrence wrote:
I agree with Kasper. You are better off just leaving initialize() to
its default implementation. Violating that abstraction for the purpose
of testing is only going to put your software more at risk, defeating
the purpose of testing.
Overriding initialize() makes it do more than just set slots, but then
there's no simple way to just initialize an object with specific slot
values.
Put another way, if you think of software as an onion of abstraction
layers, initialize() is at the bottom, and making it do more raises it
up a level, which is disruptive.
Michael
On Thu, Sep 28, 2017 at 10:00 AM, Kasper Daniel Hansen
<kasperdanielhan...@gmail.com> wrote:
Ok, this is answering a different question, but the recommendation is to
avoid spending time on the initialize method and instead write am explicit
constructor function.
On Thu, Sep 28, 2017 at 10:48 AM, Zach Skidmore <zskid...@wustl.edu> wrote:
Hi All,
I maintain the GenVisR package and am currently converting it to S4
classes. I'm running into a problem however when writing unit tests for
functions within the initalizer. What I really need is a "mock" object of
the class for which the initializer unit tests are being performed but
which hold no data. This will allow me to step through the initializer "sub
functions" and write tests for each one. The problem is I don't see a way
in the S4 system to create a mock object. I've found this post that will do
what I want
https://urldefense.proofpoint.com/v2/url?u=http-3A__r.789695.n4.nabble.com_Using-2Da-2Dmock-2Dof-2Dan-2DS4-2Dclass-2D&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=09aZdeqljGIeuqC3xMM9jZiWiYiGk8FLCdpazy2oAZ8&e=
td4728547.html, however when using this solution R CMD CHECK throws
errors:
* checking dependencies in R code ... WARNING
Unexported object imported by a ':::' call: ‘methods:::C_new_object’
See the note in ?`:::` about the use of this operator.
Including base/recommended package(s):
‘methods’
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... WARNING
Foreign function call to a base package:
.Call(methods:::C_new_object, ...)
Packages should not make .C/.Call/.External/.Fortran calls to a base
package. They are not part of the API, for use only by R itself and
subject to change without notice.
I'm wondering if anyone has any ideas on the best way to handle this. I
suppose i could create a "test" flag within the initalizer that would
create an empty object of that class and use that but it seems hacky to do
this.
thanks!
Zach
________________________________
The materials in this message are private and may contain Protected
Healthcare Information or other information of a sensitive nature. If you
are not the intended recipient, be advised that any unauthorized use,
disclosure, copying or the taking of any action in reliance on the contents
of this information is strictly prohibited. If you have received this email
in error, please immediately notify the sender via telephone or return mail.
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
