Re: [Rd] Pb with .findInheritedMethods
Seth Falcon wrote: > John Chambers <[EMAIL PROTECTED]> writes: > >> As I mentioned, this relates to writing methods for initialize(). >> Imagine someone else extends the class "Ab", for which you wrote a >> method. If they add slots to their class and you do not pass down ... >> to callNextMethod(), then you have blocked users from setting values >> for those slots in calls to new(), since the ... argument is thrown >> away by your method. >> > > If you have written an initialize method, then it is likely because > you want to do something other than just fill slots. A subclass will > most likely need to define its own initialize method and in this case, > I'm not sure passing ... will matter. > On the contrary, a small change to an existing class often does NOT involve any special treatment, just perhaps adding a bit more information. By breaking the ... argument you force the implementer of this class to write an initialize() method whether they want to or not. > >> The other aspect to this is that the last specialized method in your >> chain of class definitions should end up with: callNextMethod(.Object, >> ...) Then the default initialize() method will set values for named >> slots. >> > > Unless that isn't the behavior one desires (and I would claim this is > a rather common situation). As part of the user interface to the > class, the developer may want to decouple the intitialization > interface from specific slot names. > You can do whatever you choose for your class definition. This is an issue of allowing others to extend what you have done in the way that _they_ choose. Again, the point is to avoid the position that I know best and no one can extend my class definition by small improvements. So you block users who might manage a simple addition of a slot that they need, but would be intimidated by writing an initialize() method, or more likely, would not realize that they were required to do so. If I sound a little grumpy on this, it's that I think it's an aspect of the philosophy of gradual improvement and that philosophy is one of the good things about the language, and about the class/method mechanism. > > + seth > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
John Chambers <[EMAIL PROTECTED]> writes: > As I mentioned, this relates to writing methods for initialize(). > Imagine someone else extends the class "Ab", for which you wrote a > method. If they add slots to their class and you do not pass down ... > to callNextMethod(), then you have blocked users from setting values > for those slots in calls to new(), since the ... argument is thrown > away by your method. If you have written an initialize method, then it is likely because you want to do something other than just fill slots. A subclass will most likely need to define its own initialize method and in this case, I'm not sure passing ... will matter. > The other aspect to this is that the last specialized method in your > chain of class definitions should end up with: callNextMethod(.Object, > ...) Then the default initialize() method will set values for named > slots. Unless that isn't the behavior one desires (and I would claim this is a rather common situation). As part of the user interface to the class, the developer may want to decouple the intitialization interface from specific slot names. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
Herve Pages wrote:
>
> More generally I don't see what's wrong with not passing
> to callNextMethod all the arguments coming from the call
> to new:
>
> setClass("A", representation(toto="integer"))
> setMethod("initialize", "A", function(.Object, toto0) [EMAIL PROTECTED]
> <- as.integer(toto0); .Object})
> new("A", 45.1)
>
> setClass("Ab", contains="A")
> setMethod("initialize", "Ab", function(.Object, x, y)
> callNextMethod(.Object, x*y+1))
> new("Ab", 5, 2)
>
As I mentioned, this relates to writing methods for initialize().
Imagine someone else extends the class "Ab", for which you wrote a
method. If they add slots to their class and you do not pass down ...
to callNextMethod(), then you have blocked users from setting values for
those slots in calls to new(), since the ... argument is thrown away by
your method.
So in your example, it's more socially responsible to add "..." as a
formal argument to your method, and then to pass it on to callNextMethod():
setMethod("initialize", "Ab", function(.Object, x, y, ...)
callNextMethod(.Object, x*y+1, ...))
The other aspect to this is that the last specialized method in your chain of
class definitions should end up with:
callNextMethod(.Object, ...)
Then the default initialize() method will set values for named slots. Again,
the point is to allow others to extend your class definitions.
>
> Regards,
>
> H.
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
Hi John,
John Chambers wrote:
> A problem with callNextMethod, which is caching an inherited method as
> if it was not inherited, causing confusion on the next search. Should
> be fairly easy to fix, but may be a while before I get time to do so.
>
> By the way, I hope your simplified example does not reflect what
> happens in the actual one.
>callNextMethod(.Object)
> throws away all the ... arguments to new(), which rather defeats the
> purpose of having initialize() methods. Generally, callNextMethod()
> should get no arguments or all the arguments it needs, including ...
> See ?callNextMethod
Thanks for looking at this!
Yes it is a simplified version of a real case and
here .Object is all what callNextMethod() needs because
the initialize method for an "A" object takes no argument
other than .Object
More generally I don't see what's wrong with not passing
to callNextMethod all the arguments coming from the call
to new:
setClass("A", representation(toto="integer"))
setMethod("initialize", "A", function(.Object, toto0) [EMAIL PROTECTED]
<- as.integer(toto0); .Object})
new("A", 45.1)
setClass("Ab", contains="A")
setMethod("initialize", "Ab", function(.Object, x, y)
callNextMethod(.Object, x*y+1))
new("Ab", 5, 2)
Regards,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
A problem with callNextMethod, which is caching an inherited method as
if it was not inherited, causing confusion on the next search. Should
be fairly easy to fix, but may be a while before I get time to do so.
By the way, I hope your simplified example does not reflect what happens
in the actual one.
callNextMethod(.Object)
throws away all the ... arguments to new(), which rather defeats the
purpose of having initialize() methods. Generally, callNextMethod()
should get no arguments or all the arguments it needs, including ...
See ?callNextMethod
Herve Pages wrote:
> Hi again,
>
> This happens with R-2.4.0 and R-devel.
>
> Cheers,
> H.
>
> Herve Pages wrote:
>
>> Hi again,
>>
>>
>> Here is a very simplified version of a class hierarchy
>> defined in the Biobase package (Bioconductor). I post
>> here because this seems to be an S4 related problem:
>>
>> setClass("A", representation(name="character"))
>> setMethod("initialize", "A", function(.Object) [EMAIL PROTECTED] <- "I'm
>> an A"; .Object})
>>
>> setClass("Ab", contains="A")
>> setMethod("initialize", "Ab", function(.Object) callNextMethod(.Object))
>>
>> setClass("Abc", contains="Ab")
>>
>> setClass("Abcd", contains = c("Abc"))
>>
>> Now if I do:
>>
>> tmp1 <- new("Abc")
>> tmp2 <- new("Abcd")
>>
>> I get the following warning:
>>
>> Warning message:
>> Ambiguous method selection for "initialize", target "Abcd" (the
>> first of the signatures shown will be used)
>> Abc
>> Ab
>> in: .findInheritedMethods(classes, fdef, mtable)
>>
>> I don't really understand why .findInheritedMethods is
>> complaining here...
>> And if I don't do 'tmp1 <- new("Abc")' before I
>> do 'tmp2 <- new("Abcd")', then I don't get the warning
>> anymore!
>>
>> Does anybody have an explanation for this?
>>
>>
>> Thanks,
>> H.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with .findInheritedMethods
Hi again,
This happens with R-2.4.0 and R-devel.
Cheers,
H.
Herve Pages wrote:
> Hi again,
>
>
> Here is a very simplified version of a class hierarchy
> defined in the Biobase package (Bioconductor). I post
> here because this seems to be an S4 related problem:
>
> setClass("A", representation(name="character"))
> setMethod("initialize", "A", function(.Object) [EMAIL PROTECTED] <- "I'm
> an A"; .Object})
>
> setClass("Ab", contains="A")
> setMethod("initialize", "Ab", function(.Object) callNextMethod(.Object))
>
> setClass("Abc", contains="Ab")
>
> setClass("Abcd", contains = c("Abc"))
>
> Now if I do:
>
> tmp1 <- new("Abc")
> tmp2 <- new("Abcd")
>
> I get the following warning:
>
> Warning message:
> Ambiguous method selection for "initialize", target "Abcd" (the
> first of the signatures shown will be used)
> Abc
> Ab
> in: .findInheritedMethods(classes, fdef, mtable)
>
> I don't really understand why .findInheritedMethods is
> complaining here...
> And if I don't do 'tmp1 <- new("Abc")' before I
> do 'tmp2 <- new("Abcd")', then I don't get the warning
> anymore!
>
> Does anybody have an explanation for this?
>
>
> Thanks,
> H.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
