From jmc at r-project.org  Mon May  2 02:21:20 2011
From: jmc at r-project.org (John Chambers)
Date: Sun, 01 May 2011 17:21:20 -0700
Subject: [Rd] Reference Classes: Accessing methods via [[...]], bug?
In-Reply-To: <4DBDE093.5080300@fhcrc.org>
References: <SNT131-w42BCCDD218A68509A634CFB99D0@phx.gbl>	<BANLkTi=GvhhFmDT1=8sf0j6cM8Tsx3QJ9Q@mail.gmail.com>	<4DBDDA21.3020809@r-project.org>
	<4DBDE093.5080300@fhcrc.org>
Message-ID: <4DBDF900.1010601@r-project.org>

On 5/1/11 3:37 PM, Martin Morgan wrote:
> 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 --

Just a comment on this point:

> I am dreading the introductory class
> where one tries to explain S3, S4, and reference classes)

Well, your "introductory" class sounds a bit advanced.  :-)

My feeling is actually anticipation more than dread.  The confusion over 
what "OOP" means in S and R has been a major hassle since S3 methods 
were introduced.  I think we have an opportunity now to clarify the 
discussion as well as introduce some useful new software and better 
inter-system interfaces.

Part of the motivation for the reference classes was to bring a general 
OOP view to R.  One can start from some essential concepts of objects 
and their properties, inheritance and class definition, as have evolved 
over a very long time.

Next, there is a fundamental choice of paradigm between "encapsulated" 
OOP as the rest of the world knows it, and "functional" OOP as practiced 
by S and R, and a few other languages.  While the two paradigms are 
quite different, there is no need to view them as opposed.  They provide 
different advantages and tend to suit different goals--very roughly, 
functional object creation and reproducible results versus persistent 
objects whose properties one would like to have evolve over time using 
their encapsulated methods.

As these remarks may suggest, I'm trying to write up this perspective in 
some detail.  To be continued ....

John

 > 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
>
>



[Rd] Reference Classes: Accessing methods via [[...]], bug?
John Chambers