How about something like this where we put the accessors in
.GlobalEnv at object construction time in this example but you
could alternately place them into package:ggplot or elsewhere on
the search path:
library(proto)
make.accessors <- function(p, e = p, ...)
lapply(ls(p, ...), function(v) {
I'm trying to make wrappers to proto functions (eg. GeomPoint$new())
so that user don't notice that they're using a proto function (ie. use
geom_point()) instead. I'm hoping I can wrap proto up sufficiently
that only developers need to worry that ggplot uses a completely
different oo system.
Hadl
Not sure what the setup is here but if the objects are
intended to be proto objects then the accessor functions
could be placed in the object itself (or in an ancestor object)
rather than in the global environment. For example, this inserts
a function get.v(.) into proto object p for each variable
On 2/23/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 2/23/2007 11:05 AM, hadley wickham wrote:
> > Dear all,
> >
> > Another question related to my ggplot package: I have made some
> > substantial changes to the backend of my package so that plot objects
> > can now describe themselves much
On 2/23/2007 11:05 AM, hadley wickham wrote:
> Dear all,
>
> Another question related to my ggplot package: I have made some
> substantial changes to the backend of my package so that plot objects
> can now describe themselves much better. A consequence of this is
> that a number of convenience
Dear all,
Another question related to my ggplot package: I have made some
substantial changes to the backend of my package so that plot objects
can now describe themselves much better. A consequence of this is
that a number of convenience functions that previously I wrote by
hand, can now be wri
