From pgilbert at bank-banque-canada.ca  Fri Dec 12 18:33:38 2003
From: pgilbert at bank-banque-canada.ca (Paul Gilbert)
Date: Fri Dec 12 18:33:20 2003
Subject: [Rd] Reorganization of packages in the R distribution
In-Reply-To: <000c01c3c0ca$beadbdd0$e502eb82@maths.lth.se>
References: <000c01c3c0ca$beadbdd0$e502eb82@maths.lth.se>
Message-ID: <3FD9FBF2.5020506@bankofcanada.ca>

Henrik

Thanks for the suggestion. I am not sure that I have sufficient control 
over the functions that make an object Ttframed. I will have to explore 
a bit further to know that, and I am about to get on a plane so it will 
be awhile before I have a chance to do that. My first reaction is to 
agree with the "can get messy" observation.

Paul

Henrik Bengtsson wrote:

>>-----Original Message-----
>>From: r-devel-bounces@stat.math.ethz.ch 
>>[mailto:r-devel-bounces@stat.math.ethz.ch] On Behalf Of Paul Gilbert
>>Sent: den 12 december 2003 16:20
>>To: Prof Brian Ripley
>>Cc: Paul Gilbert; R-devel@stat.math.ethz.ch
>>Subject: Re: [Rd] Reorganization of packages in the R distribution
>>
>>
>>Prof Brian Ripley wrote:
>>
>>    
>>
>>>On Fri, 12 Dec 2003, Paul Gilbert wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Prof Brian Ripley wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>There are a small number of CRAN packages that attempt to modify 
>>>>>system functions and so will need updating.  (Known 
>>>>>          
>>>>>
>>examples are in 
>>    
>>
>>>>>dse:tframe, gregmisc and mclust and some testing code elsewhere.)
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Brian
>>>>
>>>>What do you mean by "updating?"  In tframe I modify a few
>>>>        
>>>>
>functions 
>  
>
>>>>like
>>>>
>>>>    start <- function (x, ...) if (is.Ttframed(x))
>>>>        
>>>>
>start(tframe(x),
>  
>
>>>>...) else UseMethod("start")
>>>>
>>>>If that can no longer be done then this is a serious fundamental 
>>>>change
>>>>that breaks all my code. I hope that is not what you mean. I'm
>>>>        
>>>>
>just 
>  
>
>>>>going away for a week, but will follow up when I return.
>>>>   
>>>>
>>>>        
>>>>
>>>It's always been incorrect code, and it no longer works.  You
>>>      
>>>
>should 
>  
>
>>>not be masking system generics, as the namespace 
>>>      
>>>
>>registration mechanism 
>>    
>>
>>>does not work on your version.
>>> 
>>>
>>>      
>>>
>>So what would be the proper mechanism for doing something like this?
>>    
>>
>
>  
>
>>Basically I need to do something that I believe is like multiple 
>>inheritance. I need to dispatch on the class of a certain part of an
>>    
>>
>
>  
>
>>object rather than on the object itself.  (BTW, this code has 
>>worked for 
>>about  ten years and  I believe predates your definition of  
>>"corrrect".)
>>
>>Paul
>>    
>>
>
>Hi, not knowing yours details, but here's an idea that might work.
>Under S3/UseMethod() you can "emulate" multiple inheritance by adding
>one superclass in front of the other to the class attribute. For
>instance, if ClassAA inherits from ClassA and ClassBB inherits from
>ClassB and MyClass inherits from ClassAA and ClassBB, then you'll get
>
> class(x) <- c("MyClass", "ClassAA", "ClassBB", "ClassA", "ClassB")
>
>Of course, it is important to get the order correct, and things can
>get messy if you're not careful. So, whatever function makes your
>object 'x' "Ttframed", couldn't that function at the same time add the
>superclass "TtframedClass" in front of the class vector before
>returning the object?! 
>
>However, I see a real problem if you do not control/own the functions
>that makes an object "Ttframed".
>
>Best wishes
>
>Henrik Bengtsson
>Lund University
>
>
>  
>


[Rd] Reorganization of packages in the R distribution
Paul Gilbert