[Bioc-devel] role of replaceSlots in BiocGenerics

Is this the preferred way of adjusting content in a
live object?  It is not accessible except via ":::"

        [[alternative HTML version deleted]]

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

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

Is this the preferred way of adjusting content in a
live object?  It is not accessible except via ":::"

         [[alternative HTML version deleted]]

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

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

Is this the preferred way of adjusting content in a
live object?  It is not accessible except via ":::"

         [[alternative HTML version deleted]]

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

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

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.

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

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.

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

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

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

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

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

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