> Yea, but it is super weird that as.list() filters elements out of the
> environment during coercion.
>
> I think I'm going to look through the uses of ls() inside of the core
> packages, because I suspect that is usually not necessary to extract the
> keys, and there is a cleaner (and probably fa
Some experimenting is needed. But I think a subclass is likely to be cleaner.
The official model is that methods and generic differ only in the body, so
having an object-based way to say that some methods are non-conforming feels
more natural to me.
On Jan 29, 2015, at 9:57 AM, Michael Lawren
Would we really need the special class or would simply checking the formals
of the method against those of the generic be simple and fast enough?
On Thu, Jan 29, 2015 at 9:41 AM, John Chambers wrote:
> I wouldn't want to add more to the current approach; if someone would like
> to devote some ti
I wouldn't want to add more to the current approach; if someone would like to
devote some time, the much preferable idea IMO would be to replace the whole
mechanism.
Here's one suggestion:
1. have a class, say "nonConformingMethod" for method definitions that diverge
in the argument list.
2.
I wish it didn't have to depend on the name '.local'.
Back when I wrote a lot of S4 methods I avoided the auto-generated .local
and named the local function something that made sense so that is was easier
for a user to track down the source of an error.
E.g., define the generic QQQ with numeric a
On Thu, Jan 29, 2015 at 7:57 AM, John Chambers wrote:
>
> On Jan 28, 2015, at 6:37 PM, Michael Lawrence
> wrote:
>
>> At this point I would just due:
>>
>> formals(body(method)[[2L]])
>>
>> At some point we need to figure out what to do with this .local() confusion.
>
> Agreed, definitely. The
On Thu, Jan 29, 2015 at 5:57 AM, John Chambers wrote:
>
> On Jan 28, 2015, at 6:37 PM, Michael Lawrence
> wrote:
>
> At this point I would just due:
>
> formals(body(method)[[2L]])
>
> At some point we need to figure out what to do with this .local()
> confusion.
>
>
> Agreed, definitely. The c
On Thu, Jan 29, 2015 at 5:51 AM, Martin Maechler <
maech...@lynne.stat.math.ethz.ch> wrote:
> > Michael Lawrence
> > on Tue, 27 Jan 2015 07:59:59 -0800 writes:
>
> > Since the contract of ls() is to sort, there is nothing wrong with
> > programmers depending on it. And there a
On Jan 28, 2015, at 6:37 PM, Michael Lawrence wrote:
> At this point I would just due:
>
> formals(body(method)[[2L]])
>
> At some point we need to figure out what to do with this .local() confusion.
Agreed, definitely. The current hack is to avoid re-matching arguments on
method dispatch,
> Michael Lawrence
> on Tue, 27 Jan 2015 07:59:59 -0800 writes:
> Since the contract of ls() is to sort, there is nothing wrong with
> programmers depending on it. And there are many functions that could be
> made 60X faster, but is it worth it? But I did notice that
>
On 25/01/2015 1:58 PM, Axel Urbiz wrote:
> Hello,
>
> I'm building a package on Mac OS. The build/check/install goes all ok.
> Also, the package gets loaded properly with library(my_package).
>
> However, when I call the help file for a given function in the package --
> i.e., "?my_function", I g
11 matches
Mail list logo
