Proposal for changing some of the structure in BFL.

Currently a SystemModel aggregates a ConditionalPdf, and
a MeasurementModel aggregates a also a ConditionalPdf.
This leads the user to always have to specify first the pdf and
than the model.
Commonly, at the user-level, the model implementation only
includes a constructor.

Could this aggregation be replaced by inheritance :
- SystemModel would inherit from ConditionalPdf
- MeasurementModel would inherit from ConditionalPdf.

With my limited user-experience on BFL, I can't find a case where this
would give trouble, and this would make it easier for the user.

Any Comments ?

I hereby promise not to top-post on the
BFL mailing list
BFL [..] ...


Inherit is Inherit and

Inherit is Inherit and Aggregate is Aggregate,
You worked on the problem of nested scopes for variables and functions. Then you solved the problem of data aggregates including aggregates within aggregates.


Parent class should be correct

Yes the problem can be solved by getting a class in a proper way. Also initialize the variable explaining its scope all around the class. Instance variables are responsible for all the execution.