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
<ren...@mancala.cbio.uct.ac.za> wrote:
I do not want to access the slot itself but its content: a:toto would be
a...@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...@slot1[['toto']]
- a$tata would be for a...@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...@slot1[['toto']] and
tata(a)
would return a...@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.
###
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
