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

From: Marc Schwartz <>
Date: Sat, 10 Jul 2010 10:29:21 -0500

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

> On Fri, Jul 9, 2010 at 2:10 PM, Renaud Gaujoux
> <> 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.

Marc mailing list Received on Sat 10 Jul 2010 - 15:36:04 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 Mon 12 Jul 2010 - 13:50:14 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive