Totally agree that the methods package could have a better API and better documentation.
Michael On Wed, Sep 6, 2017 at 4:16 PM, Hervé Pagès <hpa...@fredhutch.org> wrote: > On 09/06/2017 03:51 PM, Michael Lawrence wrote: >> >> On Wed, Sep 6, 2017 at 2:23 PM, Hervé Pagès <hpa...@fredhutch.org> wrote: >>> >>> Hi, >>> >>> Personally I like replaceSlots() better. >>> >>> Not only because it's more readable but also the fact that you can use >>> initialize() to update an existing object is an undocumented feature so >>> I prefer to not rely on it. >>> >> >> It seems documented to me: >> >> In the default method, unnamed arguments in the ‘...’ are >> interpreted as objects from a superclass, and named arguments are >> interpreted as objects to be assigned into the correspondingly >> named slots. > > > But before that paragraph: > > The generic function 'initialize' is not called directly. A call > to 'new' begins by copying the prototype object from the class > definition, and then calls 'intialize()' with this object as the > first argument, followed by the ... arguments. > > There are no examples showing the use of initialize() for updating an > existing object. So one has to kind of guess that it is OK to call > initialize() directly and in a context that is different from > initialization (i.e. on an "existing" object, not just on the prototype > object). > > Might be obvious for S4 wizards but I like my code to be readable by > the average developer. First time I saw the use of initialize() for > updating purpose (a few years ago), I found it quite confusing. > >> >> Granted, it could be made a lot more explicit, and it's just the >> behavior of the default method, not a general contract. >> >>> Also initialize() is a generic and there could be a method defined for >>> the object you're trying to update that won't behave the way you expect >>> (e.g. the names of its arguments won't necessarily match the names of >>> the slots). >>> >> >> This is a good point. Another best practice is not to override (or at >> least change the contract of) initialize(), but you're right, there's >> no protection against it. The documentation does make some >> recommendations along these lines. >> >>> Also validation can be expensive and there are many situations where >>> you know that you're replacing the object slots with thiings that >>> don't break the object so I like that I can call replaceSlots() with >>> check=FALSE. >>> >>> I actually wish the methods package had something like replaceSlots(). >>> >> >> Patches welcome ;) > > > Fair enough... > > H. > >> >>> H. >>> >>> On 09/06/2017 01:11 PM, Michael Lawrence wrote: >>>> >>>> >>>> No, the best practice is to just use initialize(). It used to be that >>>> replaceSlots() saved some copying, but that's no longer really the >>>> case. The only potential benefit is that it can skip validity checks, >>>> but usually you want those. >>>> >>>> Michael >>>> >>>> On Wed, Sep 6, 2017 at 12:55 PM, Vincent Carey >>>> <st...@channing.harvard.edu> wrote: >>>>> >>>>> >>>>> Is this the preferred way of adjusting content in a >>>>> live object? It is not accessible except via ":::" >>>>> >>>>> [[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=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=iXa2JnAchBDp8QpTOD4yZHTEXOMu5gjBfDOMcvQCriU&s=0Rbio7Sp7SXzPgU4xGDGkWA7V-tkgkDizVkI9JMYQ2g&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=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=iXa2JnAchBDp8QpTOD4yZHTEXOMu5gjBfDOMcvQCriU&s=0Rbio7Sp7SXzPgU4xGDGkWA7V-tkgkDizVkI9JMYQ2g&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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=6jaO_yQwpjdZEFRgOpXkRE3c70db9_YaNxuNsE0140U&s=bs9EQpJB6q_flBgWbNRGmBomFlpxmxFbWiGakiz1uuc&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 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
