The constructor should probably be doing something like this but you get
the idea:
ResubstituteParams <- function(nFeatures_call)
{
if (missing(nFeatures_call))
new("ResubstituteParams", nFeatures=seq(10, 100, 10))
else
new("ResubstituteParams",
nFeatures_call=substi
Hi Dario,
It would be good if you could provide a little bit more context about
ResubstituteParams objects and how they are typically used in practice.
As you found out, delayedAssign() won't work. How about trying something
like this?
setClassUnion("numeric_OR_NULL", c("numeric", "NULL")
The reason I mentioned the API freeze was to emphasize that we are at a
stage in our release schedule where we must be very careful to not make
changes that are potentially disruptive. I'm sorry if this suggested
that renaming a slot is changing the API. Let's be very clear on this:
it's not.
I find your arguments fairly reasonable. I wonder if you have been through
the process of restoring
data from an object serialized with the old slot names, using the revised
package. Maybe it is not even a use case for your
packages. If you have worked through the implications of this change for
Hi Vincent,
Thanks for sharing your thoughts.
I guess my thinking was that the entire point of using S4 classes and OOP is
having accessor methods to provide an implementation independent API. In the
Bioconductor guidelines it specifically tells users not to access slots using
the `@` operator
Our release schedule mentions the API freeze which happened 2 days ago:
https://bioconductor.org/developers/release-schedule/
We're in the process of finalizing the 3.14 release and many
Bioconductor developers are working hard at this time to get rid of as
much ERRORs, TIMEOUTs, and WARNINGs
I will defer to Herve about all details, but I would say that this level of
change control is implied by the "no changes
to package API without an interval of deprecation spanning at least one
release". See https://bioconductor.org/developers/how-to/deprecation/
That text mentions that removal may
Message received. I will leave that branch for later. Is this information
available on the Bioconductor website at all? It would have been useful to find
out sooner.
Best,
Chris
-Original Message-
From: Bioc-devel On Behalf Of Chris Eeles
Sent: October 15, 2021 1:10 PM
To: Hervé Pagès
On 15/10/2021 10:10, Chris Eeles wrote:
Thanks Herve,
I actually got the updateObject method working after sending this email, but
thanks for the information. Maybe it is worth adding a section on this topic to
the Bioconductor developer section?
Unfortunately, I was unaware that the start of
Thanks Herve,
I actually got the updateObject method working after sending this email, but
thanks for the information. Maybe it is worth adding a section on this topic to
the Bioconductor developer section?
Unfortunately, I was unaware that the start of development cycle was the best
time to i
Hi Chris,
There was some formatting issues with my previous answer so I'm sending
it again. Hopefully this time the formatting is better. See below.
On 14/10/2021 13:08, Chris Eeles wrote:
Hello BioC community,
I am the lead developer for the CoreGx, PharmacoGx, RadioGx and ToxicoGx
package
On 14/10/2021 13:08, Chris Eeles wrote:
Hello BioC community,
I am the lead developer for the CoreGx, PharmacoGx, RadioGx and ToxicoGx
packages. We have recently been working on major updates to the structure of a
CoreSet, which is inherited by the main class in all three of the other
pack
12 matches
Mail list logo
