Re: [Rd] Reference Classes: Generalizing Reference Class Generator objects?

From: Vitalie S. <spinuvit.list_at_gmail.com>
Date: Fri, 29 Oct 2010 22:42:08 +0200

John Chambers <jmc_at_r-project.org> writes:

> Good diagnoses.
>
> This thread brought up a point or two that needed some fixes to the documentation and code. They should be in
> r-devel and 2.12 patched (from rev. 53471).
>
> Briefly:
>
> - Initialization methods should take account of future subclasses to your class by including and passing on the
> ... argument, so that additional fields can be specified. Discussed briefly now in the $new(...) section of
> ?ReferenceClasses.
>
> - The InitFields() method is fine but was an early kludge when callSuper() didn't work for initialize(). To allow
> for the case that your class has a superclass with an initialize() method, use the callSuper() approach. There is
> an example now in the documentation.

What about, extending the generator class in general? Looking at the source I can infer that there is little that can be done about it (except rewriting the setRefClass function itself). Does that mean that the refObjectGenerator class is not supposed to be extended?

Also, tangentially related to above, why generator objects in the first place? It might have been implemented as S4 class with the slot "def" to hold the representation of refClasses. No additional generators would hang around, extension of generators would be easier and departure from S4 would be minimal.

The only reason I could think off, is the inability to write ref style methods for it. But, I must be definitely missing something here.

Thanks,
Vitalie.
>
> On 10/28/10 10:55 AM, Jon Clayden wrote:
>> ?ReferenceClasses says "Reference methods can not themselves be
>> generic functions; if you want additional function-based method
>> dispatch, write a separate generic function and call that from the
>> method". So I think you'd need to take that approach in your
>> "initialize" method.
>>
>> Hope this helps,
>> Jon
>>
>>
>> On 28 October 2010 18:25, Daniel Lee<bearlee_at_alum.mit.edu> wrote:
>>> Thank you. Your example really clarifies what the $initialize(...) function
>>> is supposed to do.
>>>
>>> Do you know if there is a straightforward way to dispatch the $new(...)
>>> method based on the signature of the arguments? I am thinking along the
>>> lines of S4 methods with valid signatures.
>>>
>>> Thanks again for the example.
>>>
>>>
>>> On 10/28/2010 12:12 PM, Jon Clayden wrote:
>>>>
>>>> Sorry - you don't need to assign the value of initFields(). I was
>>>> going to do it in two lines but then realised one was enough... :)
>>>>
>>>> TestClass<- setRefClass ("TestClass",
>>>> fields = list (text = "character"),
>>>> methods = list (
>>>> initialize = function (text) {
>>>> initFields(text=paste(text,"\n")) },
>>>> print = function () { cat(text) } )
>>>> )
>>>>
>>>> All the best,
>>>> Jon
>>>>
>>>>
>>>> On 28 October 2010 15:13, Daniel Lee<bearlee_at_alum.mit.edu> wrote:
>>>>>
>>>>> Is it possible to override the $new(...) in the reference class
>>>>> generator? I
>>>>> have tried adding a "new" method to the methods of the class, but that is
>>>>> obviously not correct. I have also tried adding it to the class
>>>>> generator,
>>>>> but the class generator still uses the default constructor.
>>>>>
>>>>> As a simple example, this is the current interface:
>>>>> TestClass<- setRefClass ("TestClass",
>>>>> fields = list (text = "character"),
>>>>> methods = list (
>>>>> print = function () {cat(text)})
>>>>> )
>>>>> test<- TestClass$new (text="Hello World")
>>>>> test$print()
>>>>>
>>>>> I would like to override $new(...) to be something like (add a "\n" to
>>>>> the
>>>>> end of the input, no need to specify input fields):
>>>>> TestClass$methods (new = function (text) {
>>>>> text<- paste (text, "\n")
>>>>> methods:::new (def, text=text)
>>>>> })
>>>>>
>>>>> The constructor would then be:
>>>>> test<- TestClass$new ("Hello World")
>>>>>
>>>>> This is a subtle, but useful change. I have also tried adding to
>>>>> TestClass a
>>>>> method $newInstance(text), but that was not successful. If this is not
>>>>> possible, could we consider augmenting the Reference Class interface to
>>>>> include constructors?
>>>>>
>>>>> ______________________________________________
>>>>> R-devel_at_r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel>>>>
>>>
>>
>> ______________________________________________
>> R-devel_at_r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 29 Oct 2010 - 20:46:28 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 29 Oct 2010 - 22:10:15 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive