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

[Renaud Gaujoux]

Thanks all.
Just to clarify a bit my intention with another '$'-like function. It 
was due to the nice features of '$':
- it hides the internal implementation
- it is known by most users so no extra brain-memory is required
- it is quick and simple to write, which I think is actually very 
important as R code is often written repeatedly over and over
- it allows for auto-completion
- it allows dynamic structures in the sense that one can allow the user 
to add its own 'members' which are accessible through the same 
interface: 'a$custom.member', 'a$builtin.member'.

I will try to work out a solution from all the suggestions I got from 
the list.
Thanks again to all.

Renaud.

-- 
Renaud Gaujoux
Computational Biology - University of Cape Town
South Africa


On 10/07/2010 17:29, Marc Schwartz wrote:
> 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:
>
>    toto(a)
>
> would return a at slot1[['toto']] and
>
>    tata(a)
>
> would return a at slot2[['tata']].
>
> Food for thought.
>
> Marc
>
>    

 

###
UNIVERSITY OF CAPE TOWN 

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.

###