[Bioc-devel] role of replaceSlots in BiocGenerics

[Hervé Pagès]

On 09/06/2017 03:53 PM, Hervé Pagès wrote:
> One of the reasons it's not exported is because it started as something
> kind of experimental and we didn't find a good home for it yet. I could
> probably move it to S4Vectors where we already have some low-level
> S4-related utils. Not the best home either but maybe better than in
> BiocGenerics?
>
> IMO using something like replaceSlots() or initialize() is still better
> than using direct slot assignment when you need to replace more than 1
> slot. It's more compact and provide an all-slots-are-modified-at-once
> semantic (atomicity) which can be useful if modifying the slots one
> after the other could temporarily create an invalid object.

... and also it provided more opportunities for optimization e.g.
generate only 1 copy of the object being modified instead of 1 copy for
each slot being modified.

H.

>
> H.
>
> On 09/06/2017 03:41 PM, Vincent Carey wrote:
>> I am getting complaints from CMD check about ::: which seems necessary to
>> use this replaceSlots facility because it is not exported.  I will look
>> into initialize,
>> which might work fine for my concern.  I cannot remember why I did not
>> just
>> use direct assignment to slots, however.  Perhaps I just found the
>> function and
>> decided using it would be better.  It would be nice to export
>> replaceSlots
>> if it does not contravene an important principle.
>>
>> On Wed, Sep 6, 2017 at 5:23 PM, Hervé Pagès <hpages at fredhutch.org
>> <mailto: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.
>>
>>     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).
>>
>>     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().
>>
>>     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 <mailto: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 <mailto: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=
>>
>>
>> <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 <mailto: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=
>>
>>
>> <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 <mailto:hpages at fredhutch.org>
>>     Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
>>     Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>>
>>
>

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