Look into Lazy Loading and Object Oriented programming

[salvafern]

Main goal: that a geometry is not requested until a user wants to display it.

I'm not sure this is the best way to go if we want an user-friendly package, but worth to look into it.

Some resources:

• https://adv-r.hadley.nz/oo.html
• https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Lazy-loading

[salvafern]

An idea would be to use R6 -> get an MRGID, and use R6 methods to navigate the triples or do specific things that we are interested in. Although this is not the typical way of using R that most people are used to.

The functions would do something like:

mr_client <- mr_gaz_mrgid$new(1234)

mr_client$summary()
#> tibble
#> prefName, source...

mr_client$relations()
#> a tibble
#> columns: relation, url to the related mrgid
#> isPartOf ..., contains...

mr_client$geometry()
#> sfc object
#> MULTIPOLYGON (...

mr_client$sources()
#> ...

What do you think @LennertSchepers @brittlnv @marc-portier @bart-v ?

[salvafern]

Lazy-loading doesn't seem to be available for R APIs packages, OO programming would be the way forward.

[marc-portier]

About the "not being used to" --> can one hide the 'new / unusal stuff' behind 'know / usual' methods or functions?

Meaning:

• if people are not used to OO/constructors --> let a factory method do the actual creation
• if people are more used to properties then to methods --> check if something like @property decoration in python exists (that would be all you need to implement the kind of lazy loading I would think we need

[salvafern]

We looked into R6 and S3. We wont use R6 as we believe is not idiomatic R and doesn't really fix issues. We will use S3 for generic functions with specific methods for each data type.

Adding geometry will be possible but not by default.