R help - Sep 2017 - To implement OO or not in R package, and if so, how to structure it?

Hello all,

I am trying to decide how to structure an R package.  Specifically, do I 
use OO classes, or just provide functions?  If the former, how should I 
structure the objects in relation to the type of data the package is 
intended to manage?

I have searched for, but haven't found, resources that guide one in the 
*decision* about whether to implement OO frameworks or not in one's R 
package.  I suspect I should, but the utility of the package would be 
aided by *collections* of objects.  R, however, doesn't seem to 
implement collections.

Background: I am writing an R package that will provide a framework for 
analyzing structural models of trees (as in trees made of wood, not 
statistical trees).  These models are generated from laser scanning 
instruments and model fitting algorithms, and hence may have aspects 
that are data-heavy.  Furthermore, coputing metrics based on these 
structures can be computationally heavy.  Finally, as a result, each 
tree has a number of metrics associated with it (which may be expensive 
to calculate), along with the underlying data of that tree.  It will be 
important as well to perform calculations across many of these trees, as 
one would do in a dataframe.

This last point is important: if one organizes data across potentially 
thousands of objects, how easy or hard is it to massage properties of 
those objects into a dataframe for analysis?

Thank you in advance for thoughts and pointers.

Allie

Hi

I do not consider myself as an expert in field of R package programming but if
your data are rectangular, why not use data.frames.

OTOH if they are structured in free form (something like lm result) you could
use lists.

Did you read this?
https://cran.r-project.org/doc/contrib/Leisch-CreatingPackages.pdf

Maybe it could give you some insight in how to create package.

Cheers
Petr
> -----Original Message-----
> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of
Alexander
> Shenkin
> Sent: Thursday, September 14, 2017 2:59 PM
> To: r-help <r-help at r-project.org>
> Subject: [R] To implement OO or not in R package, and if so, how to
structure
> it?
>
> Hello all,
>
> I am trying to decide how to structure an R package.  Specifically, do I
use OO
> classes, or just provide functions?  If the former, how should I structure
the
> objects in relation to the type of data the package is intended to manage?
>
> I have searched for, but haven't found, resources that guide one in the
> *decision* about whether to implement OO frameworks or not in one's R
> package.  I suspect I should, but the utility of the package would be aided
by
> *collections* of objects.  R, however, doesn't seem to implement
collections.
>
> Background: I am writing an R package that will provide a framework for
> analyzing structural models of trees (as in trees made of wood, not
statistical
> trees).  These models are generated from laser scanning instruments and
model
> fitting algorithms, and hence may have aspects that are data-heavy.
> Furthermore, coputing metrics based on these structures can be
> computationally heavy.  Finally, as a result, each tree has a number of
metrics
> associated with it (which may be expensive to calculate), along with the
> underlying data of that tree.  It will be important as well to perform
> calculations across many of these trees, as one would do in a dataframe.
>
> This last point is important: if one organizes data across potentially
thousands
> of objects, how easy or hard is it to massage properties of those objects
into a
> dataframe for analysis?
>
> Thank you in advance for thoughts and pointers.
>
> Allie
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
________________________________
Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou ur?eny
pouze jeho adres?t?m.
Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? neprodlen? jeho
odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie vyma?te ze sv?ho
syst?mu.
Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email
jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat.
Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi ?i
zpo?d?n?m p?enosu e-mailu.

V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?:
- vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? smlouvy, a
to z jak?hokoliv d?vodu i bez uveden? d?vodu.
- a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout;
Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany p??jemce
s dodatkem ?i odchylkou.
- trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve v?slovn?m
dosa?en?m shody na v?ech jej?ch n?le?itostech.
- odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za spole?nost
??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n nebo p?semn?
pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto emailu p??padn?
osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich existence je adres?tovi
?i osob? j?m zastoupen? zn?m?.

This e-mail and any documents attached to it may be confidential and are
intended only for its intended recipients.
If you received this e-mail by mistake, please immediately inform its sender.
Delete the contents of this e-mail with all attachments and its copies from your
system.
If you are not the intended recipient of this e-mail, you are not authorized to
use, disseminate, copy or disclose this e-mail in any manner.
The sender of this e-mail shall not be liable for any possible damage caused by
modifications of the e-mail or by delay with transfer of the email.

In case that this e-mail forms part of business dealings:
- the sender reserves the right to end negotiations about entering into a
contract in any time, for any reason, and without stating any reasoning.
- if the e-mail contains an offer, the recipient is entitled to immediately
accept such offer; The sender of this e-mail (offer) excludes any acceptance of
the offer on the part of the recipient containing any amendment or variation.
- the sender insists on that the respective contract is concluded only upon an
express mutual agreement on all its aspects.
- the sender of this e-mail informs that he/she is not authorized to enter into
any contracts on behalf of the company except for cases in which he/she is
expressly authorized to do so in writing, and such authorization or power of
attorney is submitted to the recipient or the person represented by the
recipient, or the existence of such authorization is known to the recipient of
the person represented by the recipient.

I just finished the first draft of the chapters on OO programming for
the 2nd edition of "Advanced R": https://adv-r.hadley.nz - you might
find them helpful.

Hadley

On Thu, Sep 14, 2017 at 7:58 AM, Alexander Shenkin <ashenkin at ufl.edu>
wrote:
> Hello all,
>
> I am trying to decide how to structure an R package.  Specifically, do I
use
> OO classes, or just provide functions?  If the former, how should I
> structure the objects in relation to the type of data the package is
> intended to manage?
>
> I have searched for, but haven't found, resources that guide one in the
> *decision* about whether to implement OO frameworks or not in one's R
> package.  I suspect I should, but the utility of the package would be aided
> by *collections* of objects.  R, however, doesn't seem to implement
> collections.
>
> Background: I am writing an R package that will provide a framework for
> analyzing structural models of trees (as in trees made of wood, not
> statistical trees).  These models are generated from laser scanning
> instruments and model fitting algorithms, and hence may have aspects that
> are data-heavy.  Furthermore, coputing metrics based on these structures
can
> be computationally heavy.  Finally, as a result, each tree has a number of
> metrics associated with it (which may be expensive to calculate), along
with
> the underlying data of that tree.  It will be important as well to perform
> calculations across many of these trees, as one would do in a dataframe.
>
> This last point is important: if one organizes data across potentially
> thousands of objects, how easy or hard is it to massage properties of those
> objects into a dataframe for analysis?
>
> Thank you in advance for thoughts and pointers.
>
> Allie
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.


-- 
http://hadley.nz

> Did you read this?
> https://cran.r-project.org/doc/contrib/Leisch-CreatingPackages.pdf
>
> Maybe it could give you some insight in how to create package.
That resource is ~9 years old. There are more modern treatments
available. You can read mine at http://r-pkgs.had.co.nz.

Hadley


-- 
http://hadley.nz