Should I greatly simplify the structure of the package?

[jeanmathieupotvin]

Context

Reflecting over the code I wrote for version 9002, I believe I am overkilling a simple problem. What I seek is a general interface to efficiently spawn and share schemas (or blueprints here) without having to generate the object itself. Building on that idea, the intent is to develop a couple of nice features to serialize, validate, and generate these schemas.

Here is an example of what I am seeking. Say we export only one class Schema. That class is instantiated through a call to $new(). Then, we could typically write something like below.

Example one: recursive list-like objects

# Construct the object.
mySchema <- Schema$new(
    type        = "data.table",
    constructor = data.table::data.table,
    # Define slots and types below.
    Col1 = "double",
    Col2 = "integer",
    Col3 = "complex"
)

This is nice beacause (1) it is simple and (2) it's fast. Moreover, since we are passing a function to the constructor slot, we can use this constructor as a callback function in the code whenever needed. From it, we can also detect a couple of interesting features.

# Detect if the constructor is from an environment or a namespace for package management.
parentEnv     <- environment(mySchema$constructor)
parentEnvName <- if (isNamespace(mySchema$constructor)) getNamespaceName(parentEnv) else environmentName(parentEnv)

From these simple calls, we can extract the definition of the constructor, where it is located, and how to call it if needed. Therefore, we could build a built-in package manager into the Schema class. Someone could call something like mySchema$installModules() and automatically set-up its R environment for future work. Why? Because we can detect whether the underlying namespace is installed or not. Easy work.

Example two: environments

Not as hard as someone could think. We simply embed calls to Schema$new(). Because R is currently dominated by stupid pipes, we could even make that thing work with the %>% operator and define whole environments just with just one Schema. This is attractive.

Schema$new(
    type        = "environment",
    constructor = new.env(), # Built-in R classes could avoid this argument.
    # Define the names and types of the variables scoped to the environment below.
    Obj1 = "double",
    Obj2 = "integer",
    Obj3 =  Schema$new(
        type = "integer64",
        constructor = bit64::integer64(0L)
    ),
    Obj4 = Schema$new(
        type = "S4",
        constructor = data.table::data.table(),
        Slot1 = "double",
        Slot2 = "integer",
        Slot3 = "list"
    )
)

The exact method of breaking this recursive structure into a flat one so that it works nicely with pipes remains to be determined. But this is not a hard problem. Should we consider overloading + instead to add schemas and bundle them into a bigger one?

Example three: working with pipes to flatten recursive schemas

Schema$new(
    type        = "environment",
    constructor = new.env(), # Built-in R classes could avoid this argument.
    Obj1 = "double",
    Obj2 = "integer"
) %>%
Schema$new(
    type        = "integer64",
    constructor = bit64::integer64(0L),
    "NAME?"
)

As highlighted above, the big question is how to efficiently name objects when using %>%. Could we only pass a name to ...? A character to optional name argument? Make a flexible $new() constructor? Probably. To be determined.