[Rd] Defining a method that behaves like '$'?

Marc Schwartz marc_schwartz at me.com
Sat Jul 10 17:29:21 CEST 2010

On Jul 10, 2010, at 7:24 AM, Barry Rowlingson wrote:

> On Fri, Jul 9, 2010 at 2:10 PM, Renaud Gaujoux
> <renaud at mancala.cbio.uct.ac.za> wrote:
>> I do not want to access the slot itself but its content: a:toto would be
>> a at slot1[['toto']].
>> The thing is that I would like to have two different methods: '$' (that I
>> already have) and another one to define, ideally that behaves like '$'.
>> So in brief:
>> - a:toto would be for a at slot1[['toto']]
>> - a$tata would be for a at slot2[['tata']]
>> But apparently it might not be possible.
> Even if possible, definitely not desirable. As already mentioned, a:b
> is the sequence a to b (as in 0:10), so it's going to look weird to
> anyone who hasn't noticed your definition. Also, it looks fairly
> meaningless. By which I mean there's no obvious reason why a colon
> should do what you want it to do. There's also no obvious reason why a
> dollar sign does what it does (whats it got to do with dollars?) but
> we've had it for 20 years so we're stuck with it.
> Write a method for your objects and force your users to do a bit more
> typing as a trade-off for legibility:
> slot1(a,"toto")
> is a lot more readable than a:toto (assuming you replace 'slot1' with
> something meaningful).
> Remember, code is most likely to be written once, and read many times
> - so make it easy for readers!

Just to throw in another $0.02, in hindsight, not fully understanding the context of Renaud's original query, this may be a situation where implementing relevant extractor functions would make sense. 

Consider functions such as coef(), effects(), fitted() etc. for regression models. These allow you and your users to have functions that return components of your object class without being concerned about the internal structure of your object. Importantly, you and your users will not be affected by future changes to your object structure that you may find you have to implement over time. You simply modify the extractor functions as required when the internal structure of your class changes, so that they can be used post-change, without breaking existing code.

So for example:


would return a at slot1[['toto']] and


would return a at slot2[['tata']].

Food for thought.


More information about the R-devel mailing list