I might add that the old (very old) style in Biobase was to use "new" as
constructor. That one should avoid this all the time, is a newer insight,
so you'll find plenty of old code violating this.
Kasper
On Mon, Jan 26, 2015 at 8:35 AM, Hahne, Florian
wrote:
> Thanks,
> not much need for convi
Thanks,
not much need for convincing here, just wanted a big enough push to get me
over that 'kinda works so why bother` hurdle.
I need to do other code refactoring in Gviz soon, and will take the
opportunity to kick out all initialisers in the process. So one less
package to worry about.
Florian
In the S4Vectors/IRanges infrastructure, we have never defined an
initialize method, so it is certainly possible to use the constructor
pattern in complex frameworks, and IRanges serves as a good example of
doing so. The basic pattern is to delegate to the superclass
constructor and pass that objec
Hi Michael,
I'll take a look. In order to improve my code: what exactly do you think
should be part of the initialiser, and what should be in the constructor?
There don't seem to bee any clear guidelines out there anywhere. And if
all logic goes in the constructor, how does one deal with more compl
On Fri, Jan 23, 2015 at 6:03 PM, Michael Lawrence wrote:
> I have found and fixed the affected initialize cases and will begin
> checking in fixes.
>
> Affected packages: RDAVIDWebService, flowCore (as we know), Gviz,
> ChIPseqR, Pviz, VanillaICE, flowFit.
>
> As an aside, in all of these cases, i
I have found and fixed the affected initialize cases and will begin
checking in fixes.
Affected packages: RDAVIDWebService, flowCore (as we know), Gviz,
ChIPseqR, Pviz, VanillaICE, flowFit.
As an aside, in all of these cases, initialize is implementing logic
that really belongs in a constructor f
That's right.
On Fri, Jan 23, 2015 at 12:22 PM, Mike wrote:
> Sorry, I just want to clarify some more on this.(maybe useful for others as
> well)
> What you actually mean is callNextMethod() used to drop both ... and the
> other arguments explicitly supplied from the parent call (in my case,
> pa
Sorry, I just want to clarify some more on this.(maybe useful for others
as well)
What you actually mean is callNextMethod() used to drop both |...| and
the other arguments explicitly supplied from the parent call (in my
case, |parameters| argument).
And now after your fix, both gets passed on a
The bug has existed forever. The commit log may be confusing. The
actual bug (or at least a very undesirable behavior) was in
match.call(), not callNextMethod().
I think it's still true that callNextMethod() is the natural
invocation. When adding arguments to initialize that you do not want
to pas
Michael,
Thanks for the confirmation of the issue. I see you were trying to
tackle it in the latest commits |r67467:67472| which apparently haven’t
fixed the bug yet (instead it triggers the error of the existing legacy
code in other R packages like flowCore). I can certainly change the code
t
On 01/23/2015 10:52 AM, Michael Lawrence wrote:
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
"..." to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to i
First let me apologize for my failure to read emails. There was a
long-standing bug in the methods package where arguments passed as
"..." to a method would be dropped by callNextMethod(). It turns out
that in all known cases this affects calls to initialize(), probably
because there are many initi
On 01/22/2015 12:26 AM, Martin Maechler wrote:
Mike
on Tue, 20 Jan 2015 17:16:37 -0800 writes:
> I don't think it has been addressed yet in the later commits of R-devel.
> And that piece of code in flowCore package was written long time ago and
> there is nothing wrong wit
> Mike
> on Tue, 20 Jan 2015 17:16:37 -0800 writes:
> I don't think it has been addressed yet in the later commits of R-devel.
> And that piece of code in flowCore package was written long time ago and
> there is nothing wrong with it as far as I can see.
You are right
I don't think it has been addressed yet in the later commits of R-devel.
And that piece of code in flowCore package was written long time ago and
there is nothing wrong with it as far as I can see.
Mike
On 01/20/2015 05:06 PM, Dan Tenenbaum wrote:
I'm not sure if you were implying that this ha
- Original Message -
> From: "Dan Tenenbaum"
> To: "Mike"
> Cc: Bioc-devel@r-project.org
> Sent: Tuesday, January 20, 2015 5:01:52 PM
> Subject: Re: [Bioc-devel] Latest R-devel revision breaks flowCore and other
> flow packages
>
Hi Mike,
- Original Message -
> From: "Mike"
> To: Bioc-devel@r-project.org
> Cc: "Dan Tenenbaum"
> Sent: Tuesday, January 20, 2015 4:56:43 PM
> Subject: [Bioc-devel] Latest R-devel revision breaks flowCore and other flow
> packages
>
Dan,
First of all, Thanks to the bioconductor |docker container| project that
allows me to quickly troubleshoot within the exactly same environment
that |bioc| has.
Here is the |initialize|method for |parameterFilter| which causes the
various errors from flow package vignettes.
|setMethod("in
18 matches
Mail list logo
