Merge Variable and DatedVariable

[cbenz]

See openfisca/openfisca-france#376 (comment)

When the decorator dated_function is used on a Variable like this:

class cehr(Variable):
    [...]

    @dated_function(start = date(2011, 1, 1), stop = date(2011, 12, 31))
    def function(self, simulation, period):
        return period, [...]

    @dated_function(start = date(2012, 1, 1))
    def function(self, simulation, period):
        return period, [...]

the Core should detect that it's a "dated variable" automatically.

[cbenz]

Or have only Variable classes which behave differently whether @dated_function is used or not.

[fpagnoux]

I like the second option, it makes the API simpler :)

[cbenz]

@fpagnoux I changed the issue title and description

[fpagnoux]

Following a discussion with @MattiSG and personal thoughts:

• Variable and DatedVariable should be merged (both the API and the internal structure).
  • We just have some Variable with one formula, and others with several ones.
• The start_date and stop_date variable attributes should be deprecated, as they are redundant with the decorators.
  • Some input variables have a start_date and a stop_date. This has no impact on the behaviour, as the only effect of this attribute is to deactivate the formulas. We should investigate if they have a real meaning.
• The decorator should be simplified to something like @start(2012), @start(2012, 12) or @start('2012-02') (to discuss).
• We should incentive formula writers to use the similar stop decorator only to signify that a variable has no formula after a given date. It should not be added if it is redundant with the start value of the next formula. The modality of the incentive is to be determined (doc, warning, error...).
• It should be possible to give the same name to two formulas within a variables. Currently, the first dated formula would be ignored, which is a mean trap for formula writers.

[benjello]

The variable that have no formula but a start/stop date is typically a box of the income tax form that doesn't last forever. You should not be able to set it even if it doesn't affect the computation.
And knowing its existence period is information you want to keep.

[MattiSG]

It should not be added if it is redundant with the start value of the next formula.

Solution: support stop only at the Variable level, not formula.

[MattiSG]

Partly done in #494: https://github.com/openfisca/openfisca-core/pull/494/files#diff-31e80408104c8f43c6b796a369a77585R834.

[fpagnoux]

Solution: support stop only at the Variable level, not formula.

I wonder if in some cases, we want to stop the computation of a variable through its formulas without deactivating the variable itself.

[MattiSG]

in some cases

Any example? If I recall correctly, it seems that a “temporary” removal of a variable from law which would be brought back later on, which seems like the main use case, is usually already implemented by creating a new variable to avoid confusion.

[MattiSG]

• end = 'YYYY-MM-DD' attribute on a variable if it is removed from the tax and benefit system (similarity with the <END> node).
• Rename function and @start_date annotation to formula[_YYYY[_MM[_DD]]] (default YYYY to 0001, MM and DD to 01).
• Comment out all start_date attributes on variables with no formula. This had no impact already, but contains valuable metadata.
• Do not assert that a DatedVariable can not be defined on ETERNITY.