Skip to content

Rollback dataclass approach #184

@henhuy

Description

@henhuy

This came up at #180 (comment)

Idea:
I came to the conclusion, that we should rollback implementation of dataclass facades. I do not vote going back all the way to kwargs, but instead make a mix of required, keyword-only arguments, optional arguments and kwargs.

Explanation:
The whole dataclass approach makes it very hard for inheritance (even if it was my idea originally to introduce them).
Spend way too much time to get it working last time.
The problem with dataclasses is, that they don't allow kwargs.
but we wanted to allow them in facades, so we implemented dataclass_facade which takes all parameters compares them with original dataclass parameters, puts the diff aside, initializes dataclass and adds kwargs from diff afterwards.
The problem with a child facade is, that once we added new parameters in child facade, the algorithm from above is not working anymore and initialization gets more and more complicated (decorator of child class -> init child class ->decorator of parent class -> init parent class) and it is very hard to debug.
For some reason decorator from above (see comment from above) worked, instead of dataclass_facade, but right now I cannot remember why.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions