> "Gabor" == Gabor Grothendieck <[EMAIL PROTECTED]>
> on Wed, 9 May 2007 12:32:26 -0400 writes:
Gabor> The generics don't have to be S4. In fact, in many cases it would
Gabor> be better to have them be S3 for consistency with other similar
generics
Gabor> in the core of R
TECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of S Ellison
> Sent: Wednesday, May 09, 2007 4:02 AM
> To: r-devel@r-project.org
> Subject: [Rd] One for the wish list - var.default etc
>
> I was working on a permutation-like variant of the bootstrap
> for smaller samples, and wante
The generics don't have to be S4. In fact, in many cases it would
be better to have them be S3 for consistency with other similar generics
in the core of R.
Or I wonder about the possibility of having generics which can have
some methods being of S3 and others of S4.
On 5/9/07, Robert Gentleman
Jeffrey J. Hallman wrote:
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> On Wed, 9 May 2007, S Ellison wrote:
>>
>>> Brian,
>>>
If we make functions generic, we rely on package writers implementing
the documented semantics (and that is not easy to check). That was
deemed
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Wed, 9 May 2007, S Ellison wrote:
>
> > Brian,
> >
> >> If we make functions generic, we rely on package writers implementing
> >> the documented semantics (and that is not easy to check). That was
> >> deemed to be too easy to get wrong for v
On Wed, 9 May 2007, S Ellison wrote:
> Brian,
>
>> If we make functions generic, we rely on package writers implementing
>> the documented semantics (and that is not easy to check). That was
>> deemed to be too easy to get wrong for var().
>
> Hard to argue with a considered decision, but the a
I agree that wider use of generics in the core of R is desirable as
it facilitates designs in various addon packages that are much easier
to use. In the absence of generics, the addon package either has to
clobber/mask the version in the core, which really is unacceptable, or define
a different na
Brian,
>If we make functions generic, we rely on package writers implementing the
>documented
>semantics (and that is not easy to check). That was deemed to be too
>easy to get wrong for var().
Hard to argue with a considered decision, but the alternative facing increasing
numbers of package
On Wed, 9 May 2007, S Ellison wrote:
> I was working on a permutation-like variant of the bootstrap for smaller
> samples, and wanted to be able to get summary stats of my estimator
> conveniently. mean() is OK as its a generic, so a mean.oddboot function
> gets used automatically. But var, sd
I was working on a permutation-like variant of the bootstrap for smaller
samples, and wanted to be able to get summary stats of my estimator
conveniently. mean() is OK as its a generic, so a mean.oddboot function gets
used automatically. But var, sd and others are not originally written as
gene
10 matches
Mail list logo
