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
