[Bioc-devel] role of replaceSlots in BiocGenerics

[Michael Lawrence]

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 <hpages at 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 <hpages at 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
>>>> <stvjc at 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 at 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 at 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: hpages at fredhutch.org
>>> Phone:  (206) 667-5791
>>> Fax:    (206) 667-1319
>>>
>>>
>>> _______________________________________________
>>> Bioc-devel at 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: hpages at fredhutch.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel