Hi,
Herve Pages wrote:
> Hi,
>
> It seems that new("externalptr") is always returning the same instance, and
> not a new one as one would expect from a call to new(). Of course this is hard
> to observe:
>
> > new("externalptr")
>
> > new("externalptr")
>
>
> since not a lot of detail
Luke Tierney wrote:
> On Tue, 29 Jan 2008, Herve Pages wrote:
>
>> Hi again,
>>
>> Here is an example of an annoyance that I think is directly related to
>> the
>> problem with new("externalptr"). When you try to extend the
>> "externalptr" class:
>
> You don't wnat to do that for the same reason
On Tue, 29 Jan 2008, Herve Pages wrote:
> Hi again,
>
> Here is an example of an annoyance that I think is directly related to the
> problem with new("externalptr"). When you try to extend the "externalptr"
> class:
You don't wnat to do that for the same reason you don't want to do it
with envir
Hi again,
Here is an example of an annoyance that I think is directly related to the
problem with new("externalptr"). When you try to extend the "externalptr" class:
> setClass("ExternalInteger", contains="externalptr")
[1] "ExternalInteger"
then every call to new("ExternalInteger") will ret
Hi,
It seems that new("externalptr") is always returning the same instance, and
not a new one as one would expect from a call to new(). Of course this is hard
to observe:
> new("externalptr")
> new("externalptr")
since not a lot of details are displayed.
For example, it's easy to see
