From mtmorgan at fhcrc.org  Mon May  2 00:37:07 2011
From: mtmorgan at fhcrc.org (Martin Morgan)
Date: Sun, 01 May 2011 15:37:07 -0700
Subject: [Rd] Reference Classes: Accessing methods via [[...]], bug?
In-Reply-To: <4DBDDA21.3020809@r-project.org>
References: <SNT131-w42BCCDD218A68509A634CFB99D0@phx.gbl>	<BANLkTi=GvhhFmDT1=8sf0j6cM8Tsx3QJ9Q@mail.gmail.com>
	<4DBDDA21.3020809@r-project.org>
Message-ID: <4DBDE093.5080300@fhcrc.org>

On 05/01/2011 03:09 PM, John Chambers wrote:
> Yes, as presented on that site it makes a little more sense:
>
> "While experimenting with the new reference classes in R I noticed some
> odd behaviour if you use the "[[ ]]" notation for methods
> (X[["doSomething"]] instead of X$doSomething). This notation works for
> fields, but I initially thought it wouldn't work for methods until I
> found that if you execute "class(X$doSomething)" you can then use "[[
> ]]" afterwards. The simple example below illustrates the point."
>
> For reference classes, "[[" is not meant to be used either for fields or
> methods. That it "works" at all is an artifact of the implementation
> using environments. And arguably the failure to throw an error in that
> circumstance is a bug.
>
> Please use the API as described in the ?ReferenceClasses documentation.
> These are encapsulated methods, in the usual terminology, with the
> operator "$" playing the role normally assigned to "." in other languages.
>
> A separate but related issue: It is possible to define S4 methods for
> reference classes, as discussed in a previous thread, arguably also an
> artifact in that a reference class is implemented as an S4 class of the
> same name. These are functional methods, associated with a generic
> function, and so outside the encapsulation paradigm.
>
> It would be interesting to get some experience and opinions on whether
> this is a good idea or not. It breaks encapsulation, in that the
> behavior of the class can no longer be inferred from the class
> definition alone. On the other hand, it is convenient and relates to
> "operator overloading" in some other languages.

I have written 'show' methods for reference classes (is there another 
way to pretty-print them?) and S4 methods that dispatch to reference 
methods (in particular, yield(x) on connection-like classes dispatching 
to x$yield()). The latter partly to provide end-user familiarity 
(limiting need for the beleaguered user to have to learn yet another 
syntax for invoking methods, though maybe hiding hints about important 
differences in object behavior -- I am dreading the introductory class 
where one tries to explain S3, S4, and reference classes), and partly to 
provide a distinction between a 'developer' API and a user API (again 
with questionable merits).

Martin

>
> John
>
> On 4/30/11 7:54 PM, Hadley Wickham wrote:
>> If this message is garbled for anyone else, the original question on
>> stackoverflow is here:
>> http://stackoverflow.com/questions/5841339/using-notation-for-reference-class-methods
>>
>>
>> Hadley
>>
>> On Sat, Apr 30, 2011 at 11:35 AM, Chad
>> Goymer<chad.goymer at hotmail.co.uk> wrote:
>>>
>>> I've been trying to use methods for reference classes via the
>>> notation "[[...]]" (X[["doSomething"]] rather than X$doSomething),
>>> but it failed to work. However, I did find that if you use the usual
>>> "$" notation first, "[[...]]" can be used afterwards. The following
>>> simple example illustrates the point:
>>>> setRefClass("Number", + fields = list(+ value = "numeric"+ ),+
>>>> methods = list(+ addOne = function() {+ value<<- value + 1+ }+ )+ )>
>>>> X<- new("Number", value = 1)> X[["value"]][1] 1
>>>> X[["addOne"]]()Error: attempt to apply non-function>
>>>> class(X[["addOne"]]) # NULL[1] "NULL"
>>>> class(X$addOne)[1] "refMethodDef"attr(,"package")[1] "methods"
>>>> X[["addOne"]]()> X[["value"]][1] 2> class(X[["addOne"]])[1]
>>>> "refMethodDef"attr(,"package")[1] "methods"
>>> Is this a bug?
>>> Chad Goymer
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> 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


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793



[Rd] Reference Classes: Accessing methods via [[...]], bug?
Martin Morgan